aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/connection_adapters/postgresql
Commit message (Collapse)AuthorAgeFilesLines
...
* Add `Style/RedundantFreeze` to remove redudant `.freeze`Yasuo Honda2018-09-292-5/+5
| | | | | | | | | | | | | | | | | | | | | Since Rails 6.0 will support Ruby 2.4.1 or higher `# frozen_string_literal: true` magic comment is enough to make string object frozen. This magic comment is enabled by `Style/FrozenStringLiteralComment` cop. * Exclude these files not to auto correct false positive `Regexp#freeze` - 'actionpack/lib/action_dispatch/journey/router/utils.rb' - 'activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb' It has been fixed by https://github.com/rubocop-hq/rubocop/pull/6333 Once the newer version of RuboCop released and available at Code Climate these exclude entries should be removed. * Replace `String#freeze` with `String#-@` manually if explicit frozen string objects are required - 'actionpack/test/controller/test_case_test.rb' - 'activemodel/test/cases/type/string_test.rb' - 'activesupport/lib/active_support/core_ext/string/strip.rb' - 'activesupport/test/core_ext/string_ext_test.rb' - 'railties/test/generators/actions_test.rb'
* Enable `Performance/UnfreezeString` copyuuji.yaginuma2018-09-231-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In Ruby 2.3 or later, `String#+@` is available and `+@` is faster than `dup`. ```ruby # frozen_string_literal: true require "bundler/inline" gemfile(true) do source "https://rubygems.org" gem "benchmark-ips" end Benchmark.ips do |x| x.report('+@') { +"" } x.report('dup') { "".dup } x.compare! end ``` ``` $ ruby -v benchmark.rb ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux] Warming up -------------------------------------- +@ 282.289k i/100ms dup 187.638k i/100ms Calculating ------------------------------------- +@ 6.775M (± 3.6%) i/s - 33.875M in 5.006253s dup 3.320M (± 2.2%) i/s - 16.700M in 5.032125s Comparison: +@: 6775299.3 i/s dup: 3320400.7 i/s - 2.04x slower ```
* Merge pull request #33188 from larskanis/pg-1.1Yuji Yaginuma2018-09-171-1/+7
|\ | | | | PostgreSQL: prepare for pg-1.1
| * Return empty array when casting malformed array stringsLars Kanis2018-06-231-1/+7
| | | | | | | | | | | | | | | | Parsing of malformed array strings without raising an error is deprecated in pg-1.1. It's therefore necessary to catch parser errors starting with pg-2.0. See also pg commit: https://bitbucket.org/ged/ruby-pg/commits/1b081326b346368e70c9c03ee7080e28d6b3a3dc
* | Merge pull request #32647 from eugeneius/lazy_transactionsMatthew Draper2018-08-231-0/+4
|\ \ | | | | | | Omit BEGIN/COMMIT statements for empty transactions
| * | Omit BEGIN/COMMIT statements for empty transactionsEugene Kenny2018-08-131-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a transaction is opened and closed without any queries being run, we can safely omit the `BEGIN` and `COMMIT` statements, as they only exist to modify the connection's behaviour inside the transaction. This removes the overhead of those statements when saving a record with no changes, which makes workarounds like `save if changed?` unnecessary. This implementation buffers transactions inside the transaction manager and materializes them the next time the connection is used. For this to work, the adapter needs to guard all connection use with a call to `materialize_transactions`. Because of this, adapters must opt in to get this new behaviour by implementing `supports_lazy_transactions?`. If `raw_connection` is used to get a reference to the underlying database connection, the behaviour is disabled and transactions are opened eagerly, as we can't know how the connection will be used. However when the connection is checked back into the pool, we can assume that the application won't use the reference again and reenable lazy transactions. This prevents a single `raw_connection` call from disabling lazy transactions for the lifetime of the connection.
* | | Fix bulk change table ignores comment option on PostgreSQL.Yoshiyuki Kinjo2018-08-151-1/+5
| | |
* | | Use `Array#extract!` where possiblebogdanvlviv2018-08-141-6/+8
|/ /
* | PostgreSQL 10 new relkind for partitioned tables (#31336)Yannick Schutz2018-07-271-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * PostgreSQL 10 new relkind for partitioned tables Starting with PostgreSQL 10, we can now have partitioned tables natively * Add comment * Remove extra space * Add test for partition table in postgreSQL10 * Select 'p' for "BASE TABLE" and add a test case to support PostgreSQL 10 partition tables * Address RuboCop offense * Addressed incorrect `postgresql_version` Fixes #33008. [Yannick Schutz & Yasuo Honda & Ryuta Kamizono]
* | Fix formatting of `primary_key` [ci skip]yuuji.yaginuma2018-06-241-2/+2
|/
* Make force equality checking more strictly not to allow serialized attributeRyuta Kamizono2018-05-252-0/+8
| | | | | | | | | | | Since #26074, introduced force equality checking to build a predicate consistently for both `find` and `create` (fixes #27313). But the assumption that only array/range attribute have subtype was wrong. We need to make force equality checking more strictly not to allow serialized attribute. Fixes #32761.
* `SqlTypeMetadata` is :nodoc: class [ci skip]Ryuta Kamizono2018-05-211-0/+1
| | | | So do not expose `PostgreSQLTypeMetadata` in the doc too.
* Fix multiline expression indexes for postgresql (#31621)fatkodima2018-03-161-1/+1
|
* Fix `#columsn_for_distinct` of MySQL and PostgreSQLkg8m2018-02-271-1/+1
| | | | | | | Prevent `ActiveRecord::FinderMethods#limited_ids_for` from using correct primary key values even if `ORDER BY` columns include other table's primary key. Fixes #28364.
* PostgreSQL: Allow BC dates like datetime consistentlyRyuta Kamizono2018-02-231-0/+3
| | | | | | | | | BC dates are supported by both date and datetime types. https://www.postgresql.org/docs/current/static/datatype-datetime.html Since #1097, new datetime allows year zero as 1 BC, but new date does not. It should be allowed even in new date consistently.
* PostgreSQL: Treat infinite values in date like datetime consistentlyRyuta Kamizono2018-02-232-0/+21
| | | | | | | | | | | | | | The values infinity and -infinity are supported by both date and timestamp types. https://www.postgresql.org/docs/current/static/datatype-datetime.html#DATATYPE-DATETIME-SPECIAL-TABLE And also, it can not be known whether a value is infinity correctly unless cast a value. I've added `QueryAttribute#infinity?` to handle that case. Closes #27585.
* Use private attr_readerRyuta Kamizono2018-02-231-2/+1
| | | | | Since #32028, Rails 6 requires Ruby 2.3+. No longer needed workaround for Ruby 2.2 "private attribute?" warning.
* Rails 6 requires Ruby 2.3+Jeremy Daer2018-02-171-4/+1
|
* Remove usage of strip_heredoc in the framework in favor of <<~Rafael Mendonça França2018-02-161-4/+4
| | | | | Some places we can't remove because Ruby still don't have a method equivalent to strip_heredoc to be called in an already existent string.
* Dump correctly index nulls order for postgresqlfatkodima2018-01-281-2/+6
|
* Merge pull request #31773 from dinahshi/postgresql_bulk_patchMatthew Draper2018-01-241-1/+1
|\ | | | | Postgresql bulk_change_table should flatten procs array
| * Use concat to join procs arrays in bulk_change_tableDinah Shi2018-01-231-1/+1
| |
* | Support for PostgreSQL foreign tablesfatkodima2018-01-221-1/+11
| |
* | Enable autocorrect for `Lint/EndAlignment` copKoichi ITO2018-01-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ### Summary This PR changes .rubocop.yml. Regarding the code using `if ... else ... end`, I think the coding style that Rails expects is as follows. ```ruby var = if cond a else b end ``` However, the current .rubocop.yml setting does not offense for the following code. ```ruby var = if cond a else b end ``` I think that the above code expects offense to be warned. Moreover, the layout by autocorrect is unnatural. ```ruby var = if cond a else b end ``` This PR adds a setting to .rubocop.yml to make an offense warning and autocorrect as expected by the coding style. And this change also fixes `case ... when ... end` together. Also this PR itself is an example that arranges the layout using `rubocop -a`. ### Other Information Autocorrect of `Lint/EndAlignment` cop is `false` by default. https://github.com/bbatsov/rubocop/blob/v0.51.0/config/default.yml#L1443 This PR changes this value to `true`. Also this PR has changed it together as it is necessary to enable `Layout/ElseAlignment` cop to make this behavior.
* | Correctly handle infinity value in PostgreSQL range typeyuuji.yaginuma2018-01-042-2/+10
|/ | | | | | | | An empty string is an invalid value in Ruby's range class. So need to handle `Float::INFINITY` as it is and cast it in `encode_range`. Fixes #31612
* Merge pull request #31331 from dinahshi/postgresql_bulk_updateMatthew Draper2018-01-031-5/+36
|\ | | | | Add bulk alter support for PostgreSQL
| * Add bulk alter support for PostgreSQLDinah Shi2017-12-061-5/+36
| |
* | Suppress `warning: BigDecimal.new is deprecated` in activerecordYasuo Honda2017-12-131-1/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `BigDecimal.new` has been deprecated in BigDecimal 1.3.3 which will be a default for Ruby 2.5. Refer https://github.com/ruby/bigdecimal/commit/533737338db915b00dc7168c3602e4b462b23503 ``` $ cd rails/activerecord/ $ git grep -l BigDecimal.new | grep \.rb | xargs sed -i -e "s/BigDecimal.new/BigDecimal/g" ``` - Changes made only to Active Record. Will apply the same change to other module once this commit is merged. - The following deprecation has not been addressed because it has been reported at `ActiveRecord::Result.new`. `ActiveRecord::Result.ancestors` did not show `BigDecimal`. * Not addressed ```ruby /path/to/rails/activerecord/lib/active_record/connection_adapters/mysql/database_statements.rb:34: warning: BigDecimal.new is deprecated ``` * database_statements.rb:34 ```ruby ActiveRecord::Result.new(result.fields, result.to_a) if result ``` * ActiveRecord::Result.ancestors ```ruby [ActiveRecord::Result, Enumerable, ActiveSupport::ToJsonWithActiveSupportEncoder, Object, Metaclass::ObjectMethods, Mocha::ObjectMethods, PP::ObjectMixin, ActiveSupport::Dependencies::Loadable, ActiveSupport::Tryable, JSON::Ext::Generator::GeneratorMethods::Object, Kernel, BasicObject] ``` This commit has been tested with these Ruby and BigDecimal versions - ruby 2.5 and bigdecimal 1.3.3 ``` $ ruby -v ruby 2.5.0dev (2017-12-14 trunk 61217) [x86_64-linux] $ gem list |grep bigdecimal bigdecimal (default: 1.3.3, default: 1.3.2) ``` - ruby 2.4 and bigdecimal 1.3.0 ``` $ ruby -v ruby 2.4.2p198 (2017-09-14 revision 59899) [x86_64-linux-gnu] $ gem list |grep bigdecimal bigdecimal (default: 1.3.0) ``` - ruby 2.3 and bigdecimal 1.2.8 ``` $ ruby -v ruby 2.3.5p376 (2017-09-14 revision 59905) [x86_64-linux] $ gem list |grep -i bigdecimal bigdecimal (1.2.8) ``` - ruby 2.2 and bigdecimal 1.2.6 ``` $ ruby -v ruby 2.2.8p477 (2017-09-14 revision 59906) [x86_64-linux] $ gem list |grep bigdecimal bigdecimal (1.2.6) ```
* Emulate JSON types for SQLite3 adapter (#29664)Ryuta Kamizono2017-12-031-4/+0
| | | | | Actually SQLite3 doesn't have JSON storage class (so it is stored as a TEXT like Date and Time). But emulating JSON types is convinient for making database agnostic migrations.
* `change_column_default` should be executed after type changingRyuta Kamizono2017-12-031-7/+8
| | | | | | | | | | | | | | | | | | | | If do not execute a type changing first, filling in default value may be failed. ``` % ARCONN=postgresql be ruby -w -Itest test/cases/migration/compatibility_test.rb -n test_legacy_change_column_with_null_executes_update Using postgresql Run options: -n test_legacy_change_column_with_null_executes_update --seed 20459 E Error: ActiveRecord::Migration::CompatibilityTest#test_legacy_change_column_with_null_executes_update: StandardError: An error has occurred, this and all later migrations canceled: PG::StringDataRightTruncation: ERROR: value too long for type character varying(5) : UPDATE "testings" SET "foo"='foobar' WHERE "foo" IS NULL ```
* Extract duplicated index column options normalization as ↵Ryuta Kamizono2017-12-031-0/+12
| | | | | | | `options_for_index_columns` And placed `add_options_for_index_columns` in `schema_statements.rb` consistently to ease to find related code.
* Refactor `length`, `order`, and `opclass` index options dumpingRyuta Kamizono2017-12-031-11/+5
|
* Merge pull request #31230 from dinahshi/postgresql_extract_sqlMatthew Draper2017-12-031-33/+53
|\ | | | | Extract sql fragment generators from PostgreSQL adapter
| * Extract sql fragment generators for alter table from PostgreSQL adapterDinah Shi2017-12-021-33/+53
| |
* | Fix method name in `validate_constraint` doc [ci skip]yuuji.yaginuma2017-12-021-1/+1
| |
* | Add support for invalid foreign keys in PostgresTravis Hunter2017-12-013-1/+68
| | | | | | | | Add validate_constraint and update naming
* | Add support for PostgreSQL operator classes to add_indexGreg Navis2017-11-301-12/+20
|/ | | | | | | | | | | | Add support for specifying non-default operator classes in PostgreSQL indexes. An example CREATE INDEX query that becomes possible is: CREATE INDEX users_name ON users USING gist (name gist_trgm_ops); Previously it was possible to specify the `gist` index but not the custom operator class. The `add_index` call for the above query is: add_index :users, :name, using: :gist, opclasses: {name: :gist_trgm_ops}
* Implement `PostgreSQL::SchemaDumper#extensions`Yasuo Honda2017-10-251-0/+12
| | | | | | | and abstract `SchemaDumper#extensions` is now an empty method. Since #30337, every database adapter has its own `SchemaDumper`. `extensions` are only supported by PostgreSQL database and postgresql database adapter.
* Remove `supports_disable_referential_integrity?`Yasuo Honda2017-10-231-25/+17
| | | | | | | | | | | | | | | | `supports_disable_referential_integrity?` used to handle if PostgreSQL database supports `ALTER TABLE <table name> DISABLE/ENABLE TRIGGER` statements. Refer https://github.com/rails/rails/commit/9a947af0e79cfb8692eb7e5ae94c1b8c40756f49 These statements have been documented since 8.1. https://www.postgresql.org/docs/8.1/static/sql-altertable.html > DISABLE/ENABLE TRIGGER Now Rails supports PostgreSQL 9.1 or higher only. No need to handle `supports_disable_referential_integrity?` anymore. Also, this method does not exist in any other adapters including AbstractAdapter.
* Remove deprecated argument `name` from `#indexes`Rafael Mendonça França2017-10-231-9/+1
|
* Remove deprecated argument `default` from `index_name_exists?`Rafael Mendonça França2017-10-231-6/+1
|
* [Active Record] require => require_relativeAkira Matsuda2017-10-211-21/+21
| | | | This basically reverts 9d4f79d3d394edb74fa2192e5d9ad7b09ce50c6d
* Fix longer sequence name detection for serial columns (#28339)Ryuta Kamizono2017-10-152-1/+22
| | | | | | | | We already found the longer sequence name, but we could not consider whether it was the sequence name created by serial type due to missed a max identifier length limitation. I've addressed the sequence name consideration to respect the max identifier length. Fixes #28332.
* `Postgres::OID::Range` serializes to a `Range`, quote in `Quoting`Thomas Cannon2017-09-262-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PostgreSQL 9.1+ introduced range types, and Rails added support for using this datatype in ActiveRecord. However, the serialization of `PostgreSQL::OID::Range` was incomplete, because it did not properly quote the bounds that make up the range. A clear example of this is a `tsrange`. Normally, ActiveRecord quotes Date/Time objects to include the milliseconds. However, the way `PostgreSQL::OID::Range` serialized its bounds, the milliseconds were dropped. This meant that the value was incomplete and not equal to the submitted value. An example of normal timestamps vs. a `tsrange`. Note how the bounds for the range do not include their milliseconds (they were present in the ruby Range): UPDATE "iterations" SET "updated_at" = $1, "range" = $2 WHERE "iterations"."id" = $3 [["updated_at", "2017-09-23 17:07:01.304864"], ["range", "[2017-09-23 00:00:00 UTC,2017-09-23 23:59:59 UTC]"], ["id", 1234]] `PostgreSQL::OID::Range` serialized the range by interpolating a string for the range, which works for most cases, but does not work for timestamps: def serialize(value) if value.is_a?(::Range) from = type_cast_single_for_database(value.begin) to = type_cast_single_for_database(value.end) "[#{from},#{to}#{value.exclude_end? ? ')' : ']'}" else super end end (byebug) from = type_cast_single_for_database(value.begin) 2010-01-01 13:30:00 UTC (byebug) to = type_cast_single_for_database(value.end) 2011-02-02 19:30:00 UTC (byebug) "[#{from},#{to}#{value.exclude_end? ? ')' : ']'}" "[2010-01-01 13:30:00 UTC,2011-02-02 19:30:00 UTC)" @sgrif (the original implementer for Postgres Range support) provided some feedback about where the quoting should occur: Yeah, quoting at all is definitely wrong here. I'm not sure what I was thinking in 02579b5, but what this is doing is definitely in the wrong place. It should probably just be returning a range of subtype.serialize(value.begin) and subtype.serialize(value.end), and letting the adapter handle the rest. `Postgres::OID::Range` now returns a `Range` object, and `ActiveRecord::ConnectionAdapters::PostgreSQL::Quoting` can now encode and quote a `Range`: def encode_range(range) "[#{type_cast(range.first)},#{type_cast(range.last)}#{range.exclude_end? ? ')' : ']'}" end ... encode_range(range) #=> "['2010-01-01 13:30:00.670277','2011-02-02 19:30:00.745125')" This commit includes tests to make sure the milliseconds are preserved in `tsrange` and `tstzrange` columns
* Extract `integer_like_primary_key_type` to ease to handle it for adaptersRyuta Kamizono2017-09-251-6/+3
|
* Move integer-like primary key normalization to `new_column_definition`Ryuta Kamizono2017-09-231-7/+12
| | | | | | Currently the normalization only exists in `primary_key` shorthand. It should be moved to `new_column_definition` to also affect to `add_column` with primary key.
* Fix collided sequence name detectionRyuta Kamizono2017-09-181-1/+8
| | | | | | If collided named sequence already exists, newly created serial column will generate alternative sequence name. Fix sequence name detection to allow the alternative names.
* Fix `quote_default_expression` for UUID with array defaultRyuta Kamizono2017-09-081-1/+1
| | | | Fixes #30539.
* Refactor `SchemaDumper` to make it possible to adapter specific customizationRyuta Kamizono2017-08-222-1/+5
| | | | | | | Currently `SchemaDumper` is only customizable for column options. But 3rd party connection adapters (oracle-enhanced etc) need to customizable for table or index dumping also. To make it possible, I introduced adapter specific `SchemaDumper` classes for that.
* Remove deprecated `#migration_keys`Ryuta Kamizono2017-08-221-5/+0
|