| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
* Don't force PKs on tables that have explicitly opted out
* All integer-like PKs are autoincrement unless they have an explicit
default
|
|
|
|
|
|
|
|
|
|
| |
mtsmfm/disable-referential-integrity-without-superuser-privileges"
This reverts commit eeac6151a55cb7d5f799e1ae33aa64a839cbc3aa, reversing
changes made to 5c40239d3104543e70508360d27584a3e4dc5baf.
Reason: Broke the isolated tests.
https://travis-ci.org/rails/rails/builds/188721346
|
|\
| |
| |
| |
| | |
mtsmfm/disable-referential-integrity-without-superuser-privileges
Use `SET CONSTRAINTS` for `disable_referential_integrity` without superuser privileges
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
privileges
ref: 72c1557254
- We must use `authors` fixture with `author_addresses` because of its foreign key constraint.
- Tests require PostgreSQL >= 9.4.2 because it had a bug about `ALTER CONSTRAINTS` and fixed in 9.4.2.
|
|\ \
| | |
| | |
| | |
| | | |
kamipo/fix_select_rows_method_signature_for_consistency
Fix `select_rows` method signature for consistency
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Related #22973, #24708.
`select_all`, `select_one`, `select_value`, and `select_values` method
signature is `(arel, name = nil, binds = [])`.
But `select_rows` is `(sql, name = nil, binds = [])`.
|
| | | |
|
|/ /
| |
| |
| |
| | |
Passing `name` to `tables` is already deprecated at #21601.
Passing `name` to `indexes` is also unused.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Per the regression commit below, the commit changes the behavior of
`#changed?`to consult the `#changed_in_place?` method on `Type::Value` classes.
Per this change, `PostgreSQL::OID::Hstore` needs to override this method
in order to compare the deserialized forms of the two arguments. In
Ruby, two hashes are considered equal even if their key order is
different. This commit helps to bring that behavior to `Hstore` values.
Fixes regression introduced by 8e633e505880755e7e366ccec2210bbe2b5436e7
Fixes #27502
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In f1a0fa9 we moved backend specific timestamp behavior out of the type
and into the adapter. This was in line with our general attempt to
reduce the number of adapter specific type subclasses. However, on PG,
the array type performs all serialization, including database encoding
in its serialize method.
This means that we have converted the value into a string before
reaching the database, so no adapter specific logic can be applied (and
this also means that timestamp arrays were using the default `.to_s`
method on the given object, which likely meant timestamps were being
ignored in certain cases as well)
Ultimately I want to do a more in depth refactoring which separates
database serializer objects from the active model type objects, to give
us a less awkward API for introducing the attributes API onto Active
Model.
However, in the short term, we follow the solution we've applied
elsewhere for this. Move behavior off of the type and into the adapter,
and use a data object to allow the type to communicate information up
the stack.
Fixes #27514.
|
| |
| |
| |
| |
| | |
Currently schema dumper does not dump array subtype `precision` and
`scale` options. This commit fixes the issue.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
The visibility of all internal protected methods was changed to private
since 5b14129.
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Make `:auto_increment` option works on `:bigint`
|
| | |
| | |
| | |
| | | |
Follow up to #27272.
|
|/ / |
|
|/
|
|
|
|
| |
Using `:auto_increment` option for abstracting the DB-specific auto
incremental types. It is worth to ease to implement the compatibility
layer.
|
|
|
|
|
|
|
| |
- Mentioned clearly that for PostgreSQL < 9.4, you need to pass the
default option with "uuid_generate_v4()"
- Also updated PostgreSQL Active Record guide with this change.
- https://github.com/rails/rails/pull/25395#r66877078
|
|
|
|
|
|
|
|
|
|
| |
Since 9.4, PostgreSQL recommends using `pgcrypto`'s `gen_random_uuid()`
to generate version 4 UUIDs instead of the functions in the `uuid-ossp`
extension.
These changes uses the appropriate UUID function depending on the
underlying PostgreSQL server's version, while maintaining
`uuid_generate_v4()` in older migrations.
|
|\
| |
| | |
use `force_encoding` instread of `encode!` to avoid `UndefinedConversionError`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`PG::TextEncoder::Array#encode` returns the encoded value with `ASCII-8BIT`.
But in some cases, trying to convert `ASCII-8BIT` to `UTF-8` cause an error.
```ruby
"{\xE3\x83\x95\xE3\x82\xA1\xE3\x82\xA4\xE3\x83\xAB}".encode!(Encoding::UTF_8)
# => Encoding::UndefinedConversionError: "\xE3" from ASCII-8BIT to UTF-8
```
Should use `force_encoding` to avoid this error.
Follow up to 7ba3a48df5bfdc5e98506bb829f937e03b55a5b3
Ref: https://github.com/rails/rails/pull/23619#issuecomment-189924036
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As reported via #26904, there is a regression in how values for
Postgres' HStore column type are being processed, beginning in Rails 5.
Currently, the way that Active Record checks whether or not values need
to be serialized and put into the correct storage format is whether or
not it is a `Hash` object. Since `ActionController::Parameters` no
longer inherits from `Hash` in Rails 5, this conditional now returns
false. To remedy this, we are now checking to see whether the `value`
parameters being passed in responds to a certain method, and then
calling the `serialize` method, except this time with a real Hash
object. Keeping things DRY!
Fixes #26904.
|
|\
| |
| | |
Add missing `+` around a some literals.
|
| |
| |
| |
| |
| |
| | |
Mainly around `nil`
[ci skip]
|
| |
| |
| |
| | |
that accepts results of SHOW FIELDS
|
| | |
|
| |
| |
| |
| |
| | |
A query may wait on a database-level lock, which could lead to a
deadlock between threads.
|
|/
|
|
| |
Follow up to 99cf7558000090668b137085bfe6bcc06c4571dc.
|
|
|
|
| |
If does not quote table name properly, invalid SQL is generated.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Follow up to #26735.
If `table_options` returns `{ comment: nil }`, `create_table` line is
broken.
Example:
```ruby
create_table "accounts", force: :cascade, do |t|
```
|
|
|
|
|
|
|
|
| |
Per discussion in pull request #26622:
"Let's change it to PG::Error. The more specific classes mentioned are
subclasses, and the fact the raised exception is a PG::UndefinedColumn
doesn't change the fact that it's also a PG::Error." - matthewd
|
|
|
|
|
| |
This clarifies the object that +ActiveRecord::Base.connection.execute+
will return when using Postgresql.
|
|
|
|
|
|
|
|
|
| |
Recently, the Rails team made an effort to keep the source code consistent, using Ruboco
(bb1ecdcc677bf6e68e0252505509c089619b5b90 and below). Some of the case
statements were missed.
This changes the case statements' formatting and is consistent with changes
in 810dff7c9fa9b2a38eb1560ce0378d760529ee6b and db63406cb007ab3756d2a96d2e0b5d4e777f8231.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
There are some minor changes to the point type as I had forgotten that
this will affect the behavior of `t.point` in migrations and the schema
dumper so we need to handle those as well.
I'll say this again so I can convince myself to come up with a better
structure... TYPES SHOULD NOT CARE ABOUT SCHEMA DUMPING AND WE NEED TO
BETTER SEPARATE THESE.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I still think that this is something that should be handled in the pg
gem, but it's not going to end up happening there so we'll do it here
instead. Once we bump to pg 0.19 we can pass the encoding to the
`encode` method instead.
This issue occurs because C has no concept of encoding (or strings,
really). The bytes that we pass here when sending the value to the
database will always be interpreted as whatever encoding the connection
is currently configured to use. That means that roundtripping to the
database will lose no information
However, after assigning we round trip through our type system without
hitting the database. The only way that we can do the "correct" thin
here would be to actually give a reference to the connection to the
array type and have it check the current value of the connection's
encoding -- which I'm strongly opposed to. We could also pass in the
encoding when it's constructed, but since that can change independently
of the type I'm not a huge fan of that either.
This feels like a reasonable middle ground, where if we have an array of
strings we simply use the encoding of the string we're given.
Fixes #26326.
|
|
|
|
| |
Fixes #26137.
|
|
|
|
|
| |
Because `sql_for_insert` is only called in `use_insert_returning?` is
true since #26002.
|
|\
| |
| |
| |
| | |
kamipo/sql_for_insert_should_be_called_inside_exec_insert
`sql_for_insert` should be called inside `exec_insert`
|
| |
| |
| |
| |
| | |
`exec_insert` cannot return last inserted id if `use_insert_returning?`
is true. `sql_for_insert` should be called inside `exec_insert`.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| | |
|
| | |
|
|/
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
| |
`insert`, `update`, `delete`, and `exec_query` have a default value
against `name` and `binds`. But `exec_insert`, `exec_update`, and
`exec_delete` not have. It is an inconvenience and inconsistent.
|
|\
| |
| | |
Prevent `table_comment` query if a table doesn't have a comment
|