| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
Slightly refactoring `PostgreSQLColumn`. `array` should be readonly.
`default_function` should be initialized by `super`. `sql_type` has been
removed `[]`. Since we already choose to remove it we should not change.
|
|
|
|
|
| |
In most cases, `create_table_definition` called by table_name (the first
argument) only.
|
|
|
|
| |
If it is not a default primary key, correctly dump the type and options.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PG doesn't register it's types using the `int(4)` format that others do.
As such, if we alias `int8` to the other integer types, the range
information is lost. This is fixed by simply registering it separately.
The other option (which I specifically chose to avoid) is to pass the
information of the original type that was being aliased as an argument.
I'd rather avoid that, since an alias should truly be treated the same.
If we need different behavior for a different type, we should explicitly
register it with that, and not have a conditional based on aliasing.
Fixes #18144
[Sean Griffin & ysbaddaden]
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type registration was simply looking for the OID, and eagerly
fetching/constructing the sub type when it was registered. However,
numeric types have additional parameters which are extracted from the
actual SQL string of the type during lookup, and can have their behavior
change based on the result.
We simply need to use the block form of registration, and look up the
subtype lazily instead.
Fixes #17935
|
| |
|
|
|
|
| |
Fixes: https://github.com/rails/rails/issues/17856.
|
|
|
|
|
|
|
|
| |
I grepped the source code for code snippets wrapped in backticks in the comments
and replaced the backticks with plus signs so they are correctly displayed in
the Rails documentation.
[ci skip]
|
|
|
|
| |
This reverts commit da99a2a2982d35f670ad9647463e09bfe9032b70.
|
| |
|
|
|
|
|
| |
also increase the version of pg required so that people will get the
GVL friendly version
|
| |
|
|
|
|
|
| |
MySQL reports the column name as `"MAX(developer_id)"`. PG will report
it as `"max"`
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `select` method has the same definition in almost all database
adapters, so it can be moved from the database-specific adapters
(PostgreSQl, MySQL, SQLite) to the abstract `database_statement`:
```ruby
def select(sql, name = nil, binds = [])
exec_query(sql, name, binds)
end
```
---
More details about this commit: the only two DB-specific adapters
that have a different definition of `select` are MySQLAdapter and
MySQL2Adapter.
In MySQLAdapter, `select` invokes `exec_query(sql, name, binds)`, so
calling `super` achieves the same goal with less repetition.
In MySQL2Adapter, `select` invokes `exec_query(sql, name)`, that is,
it does not pass the `binds` parameter like other methods do. However,
[MySQL2Adapter's `exec_query`](https://github.com/rails/rails/blob/74a527cc63ef56f3d0a42cf638299958dc7cb08c/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb#L228L231)
works exactly the same whether this parameters is passed or not, so the output
does not change:
```ruby
def exec_query(sql, name = 'SQL', binds = [])
result = execute(sql, name)
ActiveRecord::Result.new(result.fields, result.to_a)
end
```
|
|
|
|
|
|
|
|
| |
In the DSL you can now do:
create_table(:foos) do |t|
t.bigint :hi
end
|
|
|
|
|
|
| |
it doesn't work on SQLite3 since it doesn't support truncate, but that's
OK. If you call truncate on the connection, you're now bound to that
database (same as if you use hstore or any other db specific feature).
|
|
|
|
|
|
|
| |
`AbstractAdapter#supports_views?` defaults to `false` so we have to turn it on
in adapter subclasses. Currently the flag only controls test execution.
/cc @yahonda
|
| |
|
|
|
|
| |
[Philippe Creux, Chris Teague]
|
| |
|
|
|
|
| |
Fix CVE-2014-3483 and protect against CVE-2014-3482.
|
|
|
|
|
|
|
|
| |
The only case where we got a column that was not `nil`, but did not
respond to `cast_type` was when type casting the default value during
schema creation. We can look up the cast type, and add that object to
the column definition. Will allow us to consistently rely on the type
objects for type casting in all directions.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Attempting to reduce the number of places that care about the details of
how type casting occurs. We remove the type casting of the primary key
in `JoinDependecy`, rather than encapsulating it. It was originally
added for consistency with
https://github.com/rails/rails/commit/40898c8c19fa04442fc5f8fb5daf3a8bdb9a1e03#diff-06059df8d3dee3101718fb2c01151ad0R211,
but that conditional was later removed in
https://github.com/rails/rails/commit/d7ddaa530fd1b94e22d745cbaf2e8a5a34ee9734.
What is important is that the same row twice will have the same value
for the primary key, which it will.
|
| |
|
|
|
|
|
|
|
|
| |
In some cases there is a difference between the two, we should always
be doing one or the other. For convenience, `type_cast` is still a
private method on type, so new types that do not need different behavior
don't need to implement two methods, but it has been moved to private so
it cannot be used accidentally.
|
|
|
|
| |
Whiny nils is no longer a thing, so we no longer need this optimization
|
|
|
|
|
|
|
| |
For any type that is represented as a string and then type cast, we do
not need separate regular expressions for the various types. No function
will match this regex. User defined types *should* match this, so that
the type object can decide what to do with the value.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
This is an intermediate solution. It is related to the refactoring @sgrif
is making and will change in the future.
|
|
|
|
|
|
| |
With ActiveRecord::Properties, we now have a reasonable path for users
to continue to keep this behavior if they want it. This is an edge case
that has added a lot of complexity to the code base.
|
| |
|
| |
|
|
|
|
|
|
|
| |
This mirrors the layout of abstract adapter and puts the definitions
inside the `PostgreSQL` namespace (no longer under the adapter namespace).
/cc @kares
|
| |
|
| |
|
|
|
|
|
| |
Columns and injected types no longer have any conditionals based on the
format of SQL type strings! Hooray!
|
| |
|
|
|
|
|
|
| |
Ideally types will be usable without having to specify a sql type
string, so we should keep the information related to parsing them on the
adapter or another object.
|
| |
|
|\
| |
| | |
Use the generic type map for all PG type registrations
|
| |
| |
| |
| |
| |
| |
| | |
We're going to want all of the benefits of the type map object for
registrations, including block registration and real aliasing. Moves
type name registrations to the adapter, and aliases the OIDs to the
named types
|
|/
|
|
|
|
|
|
| |
Determining things like precision and scale in postgresql will require
the given blocks to take additional arguments besides the OID.
- Adds the ability to handle additional arguments to `TypeMap`
- Passes the column type to blocks when looking up PG types
|
| |
|
|
|
|
|
| |
Using general types where possible. Several more can go away once
infinity gets figured out.
|