aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb
Commit message (Collapse)AuthorAgeFilesLines
* Return a `Point` object from the PG Point typeSean Griffin2015-06-051-0/+2
| | | | | | | | | | | | | | | | | | | This introduces a deprecation cycle to change the behavior of the default point type in the PostgreSQL adapter. The old behavior will continue to be available for the immediate future as `:legacy_point`. The current behavior of returning an `Array` causes several problems, the most significant of which is that we cannot differentiate between an array of points, and a point itself in the case of a column with the `point[]` type. The attributes API gives us a reasonable way to have a proper deprecation cycle for this change, so let's take advantage of it. If we like this change, we can also add proper support for the other geometric types (line, lseg, box, path, polygon, and circle), all of which are just aliases for string today. Fixes #20441
* Updated postgresql documentation link to use latest version [ci skip]Ronak Jangir2015-05-201-4/+4
|
* Remove `require 'arel/visitors/bind_visitor'`Ryuta Kamizono2015-05-191-2/+0
| | | | | This line introduced by the commit fd398475 for using `Arel::Visitors::BindVisitor`. Currently it is not used.
* Eliminate the duplication code of `StatementPool`Ryuta Kamizono2015-05-191-27/+1
|
* Use `select_value` for avoid `ActiveRecord::Result` instance creatingRyuta Kamizono2015-05-051-1/+1
| | | | | `exec_query` create `ActiveRecord::Result` instance. It is better to use `select_value` instead of `exec_query` for performance.
* PostgreSQL: `:collation` support for string and text columnsRyuta Kamizono2015-05-041-1/+3
| | | | | | | | | Example: create_table :foos do |t| t.string :string_en, collation: 'en_US.UTF-8' t.text :text_ja, collation: 'ja_JP.UTF-8' end
* Freeze static arguments for gsubbrainopia2015-04-021-2/+2
|
* Prefer string patterns for gsubbrainopia2015-04-021-1/+1
| | | | | | | | | | | | | | | | | https://github.com/ruby/ruby/pull/579 - there is a new optimization since ruby 2.2 Previously regexp patterns were faster (since a string was converted to regexp underneath anyway). But now string patterns are faster and better reflect the purpose. Benchmark.ips do |bm| bm.report('regexp') { 'this is ::a random string'.gsub(/::/, '/') } bm.report('string') { 'this is ::a random string'.gsub('::', '/') } bm.compare! end # string: 753724.4 i/s # regexp: 501443.1 i/s - 1.50x slower
* Reduce memory usage when loading types in PGSean Griffin2015-03-291-4/+10
| | | | | | | | | | | | | We were never clearing the `PG::Result` object used to query the types when the connection is first established. This would lead to a potentially large amount of memory being retained for the life of the connection. Investigating this issue also revealed several low hanging fruit on the performance of these methods, and the number of allocations has been reduced by ~90%. Fixes #19578
* PostgreSQL, Use ruby-pg's built-in capabilities for array en-/decoding in C.Lars Kanis2015-03-251-4/+4
| | | | This obsoletes the ruby based implementations.
* PostgreSQL, Add input type casts for primitive types.Lars Kanis2015-03-251-0/+10
| | | | | | | | | Ruby-pg's default way to serialize values for transmission to the database is to call #to_s . This however creates a temporary String object for each value. Setting a class based type map avoids the allocation of this additional String. The performance benefit is measurable in microbenchmarks, but not with the overhead of activerecord. However it's free to use and has no drawback.
* PostgreSQL, Fix OID based type casts in C for primitive types.Lars Kanis2015-03-251-6/+6
| | | | | | | | | | The type map was introduced in aafee23, but wasn't properly filled. This mainly adjusts many locations, that expected strings instead of integers or boolean. add_pg_decoders is moved after setup of the StatementPool, because execute_and_clear could potentially make use of it.
* Require pg~>0.18 to ensure Ruby 2.2 compatibilityMatt Brictson2015-03-111-2/+2
| | | | | | | Versions of the pg gem earlier than 0.18.0 cannot be used safely with Ruby 2.2. Specifically, pg 0.17 when used with Ruby 2.2 has a known bug that causes random bits to be added to the end of strings. Further explanation here: https://bitbucket.org/ged/ruby-pg/issue/210/crazy-bytes-being-added-to-record
* Correctly dump `serial` and `bigserial`Ryuta Kamizono2015-03-041-1/+20
|
* Add `Column#bigint?` methodRyuta Kamizono2015-03-041-1/+1
|
* Allow `:precision` option for time type columnsRyuta Kamizono2015-02-201-0/+4
|
* Extract precision from datetime and time columnsRyuta Kamizono2015-02-191-5/+2
| | | | | | | | The cause by which the test suite for the mysql adapter broke in 1502cae (reverted 89ba5bb) is because the precision was not extracted. The rounding problem in mysql adapter has not been fixed, but `mysql_56` helper tested only mysql2 adapter, its behavior was not apparent.
* Revert "Allow `:precision` option for time type columns"Sean Griffin2015-02-171-6/+5
| | | | | | | | | | This reverts commit 1502caefd30b137fd1a0865be34c5bbf85ba64c1. The test suite for the mysql adapter broke when this commit was used with MySQL 5.6. Conflicts: activerecord/CHANGELOG.md
* Register adapter specific types with the global type registrySean Griffin2015-02-151-0/+19
| | | | | | We do this in the adapter classes specifically, so the types aren't registered if we don't use that adapter. Constants under the PostgreSQL namespace for example are never loaded if we're using mysql.
* Allow `:precision` option for time type columnsRyuta Kamizono2015-02-121-5/+6
|
* Remove most PG specific type subclassesSean Griffin2015-02-111-6/+38
| | | | | | | | | The latest version of the PG gem can actually convert the primitives for us in C code, which gives a pretty substantial speed up. A few cases were only there to add the `infinity` method, which I just put on the range type (which is the only place it was used). Floats also needed to parse `Infinity` and `NaN`, but it felt reasonable enough to put that on the generic form.
* rm `Type#text?`Sean Griffin2015-02-071-0/+18
| | | | | | | | | | | | | | | | This predicate was only to figure out if it's safe to do case insensitive comparison, which is only a problem on PG. Turns out, PG can just tell us whether we are able to do it or not. If the query turns out to be a problem, let's just replace that method with checking the SQL type for `text` or `character`. I'd rather not burden the type objects with adapter specific knowledge. The *real* solution, is to deprecate this behavior entirely. The only reason we need it is because the `:case_sensitive` option for `validates_uniqueness_of` is documented as "this option is ignored for non-strings". It makes no sense for us to do that. If the type can't be compared in a case insensitive way, the user shouldn't tell us to do case insensitive comparison.
* rm `Column#cast_type`Sean Griffin2015-02-031-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The type from the column is never used, except when being passed to the attributes API. While leaving the type on the column wasn't necessarily a bad thing, I worry that it's existence there implies that it is something which should be used. During the design and implementation process of the attributes API, there have been plenty of cases where getting the "right" type object was hard, but I had easy access to the column objects. For any contributor who isn't intimately familiar with the intents behind the type casting system, grabbing the type from the column might easily seem like the "correct" thing to do. As such, the goal of this change is to express that the column is not something that should be used for type casting. The only places that are "valid" (at the time of this commit) uses of acquiring a type object from the column are fixtures (as the YAML file is going to mirror the database more closely than the AR object), and looking up the type during schema detection to pass to the attributes API Many of the failing tests were removed, as they've been made obsolete over the last year. All of the PG column tests were testing nothing beyond polymorphism. The Mysql2 tests were duplicating the mysql tests, since they now share a column class. The implementation is a little hairy, and slightly verbose, but it felt preferable to going back to 20 constructor options for the columns. If you are git blaming to figure out wtf I was thinking with them, and have a better idea, go for it. Just don't use a type object for this.
* Remove Relation#bind_paramsSean Griffin2015-01-271-5/+3
| | | | | | | | `bound_attributes` is now used universally across the board, removing the need for the conversion layer. These changes are mostly mechanical, with the exception of the log subscriber. Additional, we had to implement `hash` on the attribute objects, so they could be used as a key for query caching.
* Fix typo in PostresSQLAdapter's documentationSebastian Staudt2015-01-101-1/+1
|
* Prefer `array?` rather than `array`Ryuta Kamizono2015-01-041-1/+1
| | | | | | 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.
* Add default value for `create_table_definition`Ryuta Kamizono2015-01-031-1/+1
| | | | | In most cases, `create_table_definition` called by table_name (the first argument) only.
* Improve a dump of the primary key support.Ryuta Kamizono2014-12-291-0/+15
| | | | If it is not a default primary key, correctly dump the type and options.
* Correctly handle limit on int4 and int8 types in PGSean Griffin2014-12-221-2/+2
| | | | | | | | | | | | | | | | 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]
* Correctly respect subtypes for PG arrays and rangesSean Griffin2014-12-051-3/+6
| | | | | | | | | | | | | 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
* no need to pass native_database_types aroundYves Senn2014-12-021-1/+1
|
* Fix value extracted from negative integers for PostgreSQL.Guo Xiang Tan2014-12-011-1/+1
| | | | Fixes: https://github.com/rails/rails/issues/17856.
* Wrap code snippets in +, not backticks, in sdocclaudiob2014-11-201-2/+2
| | | | | | | | 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]
* Revert "PERF: optimise type lookup to avoid invoking procs"Sean Griffin2014-11-191-13/+7
| | | | This reverts commit da99a2a2982d35f670ad9647463e09bfe9032b70.
* PERF: optimise type lookup to avoid invoking procsSam2014-11-171-7/+13
|
* exec_prepared is GVL friendly, so lets use it.Aaron Patterson2014-11-131-4/+2
| | | | | also increase the version of pg required so that people will get the GVL friendly version
* Added SchemaDumper support for tables with jsonb columns.Ted O'Meara2014-11-041-0/+1
|
* Correctly cast calculation results on PGSean Griffin2014-11-011-0/+10
| | | | | MySQL reports the column name as `"MAX(developer_id)"`. PG will report it as `"max"`
* Remove redundant `to_s` in interpolationclaudiob2014-10-301-2/+2
|
* add bigserial pk supportAaron Patterson2014-10-291-0/+1
|
* Remove duplicate 'select' database statementclaudiob2014-10-201-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 ```
* add table.bigint supportAaron Patterson2014-10-151-0/+1
| | | | | | | | In the DSL you can now do: create_table(:foos) do |t| t.bigint :hi end
* add a truncate method to the connectionAaron Patterson2014-09-221-0/+4
| | | | | | 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).
* introduce `connection.supports_views?` and basic view tests.Yves Senn2014-09-091-0/+4
| | | | | | | `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
* Freeze ADAPTER_NAME in adaptersAbdelkader Boudih2014-09-051-6/+1
|
* Add support for Postgresql JSONBPhilippe Creux2014-07-241-0/+1
| | | | [Philippe Creux, Chris Teague]
* Don't rely on the sql type to quote XML columns in PGSean Griffin2014-07-061-1/+1
|
* Fix SQL injection when querying against ranges and bitstringsRafael Mendonça França2014-07-021-1/+1
| | | | Fix CVE-2014-3483 and protect against CVE-2014-3482.
* Always pass a column with a type object to quoteSean Griffin2014-06-281-0/+5
| | | | | | | | 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.
* fk: `add_foreign_key` and `remove_foreign_key` for PostgreSQL adapter.Yves Senn2014-06-261-0/+4
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-05 11:59:56 +0000