aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/connection_adapters/postgresql
Commit message (Collapse)AuthorAgeFilesLines
* Exclude `:name` and `:type` from `prepare_column_options`Ryuta Kamizono2016-02-291-1/+1
| | | | Actually `:name` and `:type` are not column options.
* eliminate warnings about multiple primary keys on habtm join tablesAaron Patterson2016-02-191-1/+1
| | | | | | | | habtm join tables commonly have two id columns and it's OK to make those two id columns a primary key. This commit eliminates the warnings for join tables that have this setup. ManageIQ/manageiq#6713
* `schema_type` returns symbol rather than stringRyuta Kamizono2016-02-081-3/+3
| | | | | | | | | A return value of `schema_type` is used by: 1. primary key type: using as `symbol.inspect` 2. normal column type: using as `symbol.to_s` It is better to return symbol.
* Extract `ExplainPrettyPrinter` to appropriate filesRyuta Kamizono2016-02-012-38/+43
|
* `OID::Money.precision` is unused since #15239Ryuta Kamizono2016-01-311-2/+0
| | | | | | | | p PostgreSQLAdapter::OID::Money.precision # => 19 p PostgreSQLAdapter::OID::Money.new.precision # => nil
* Revert "Merge pull request #23346 from kamipo/refactor_oid_money_precision"Rafael Mendonça França2016-01-301-4/+2
| | | | | | | This reverts commit ff835f90800a3e4122d64606cb328908c2e0e071, reversing changes made to c4d85dfbc71043e2a746acd310e32f4f04db801a. Reason: This broke the tests. We will add back after investigated.
* Refactor `OID::Money.precision`Ryuta Kamizono2016-01-301-2/+4
|
* Clarify DatabaseStatements#execute docs re: memory usage.James Coleman2016-01-221-0/+2
|
* Merge pull request #20005 from kamipo/default_expression_supportRafael França2016-01-162-11/+8
|\ | | | | Add `:expression` option support on the schema default
| * Add expression support on the schema defaultRyuta Kamizono2016-01-132-11/+8
| | | | | | | | | | | | | | | | Example: create_table :posts do |t| t.datetime :published_at, default: -> { 'NOW()' } end
* | `sql_for_insert` returns values for passing to `exec_insert`Ryuta Kamizono2016-01-151-12/+8
|/
* Refactor tz aware types, add support for PG rangesSean Griffin2016-01-082-1/+12
| | | | | | | | | | | | | | | | | This is an alternate implementation to #22875, that generalizes a lot of the logic that type decorators are going to need, in order to have them work with arrays, ranges, etc. The types have the ability to map over a value, with the default implementation being to just yield that given value. Array and Range give more appropriate definitions. This does not automatically make ranges time zone aware, as they need to be added to the `time_zone_aware` types config, but we could certainly make that change if we feel it is appropriate. I do think this would be a breaking change however, and should at least have a deprecation cycle. Closes #22875. /cc @matthewd
* Merge pull request #22973 from kamipo/fix_select_values_method_signatureRafael França2016-01-081-2/+2
|\ | | | | Fix `select_values` method signature for consistency
| * Fix `select_values` method signature for consistencyRyuta Kamizono2016-01-081-2/+2
| |
* | `{update|delete}_sql` are almost the same as `{update|delete}`Ryuta Kamizono2016-01-081-5/+0
|/ | | | Simply `{update|delete}_sql` aliases to `{update|delete}`.
* Refactor `connection.insert_sql`Ryuta Kamizono2016-01-071-16/+2
| | | | `connection.insert_sql` is almost the same as `connection.insert`.
* Fix `connection#create` in PG adapterRyuta Kamizono2016-01-051-4/+0
| | | | | | Originally `connection#create` had aliased to `connection#insert` in PG adapter. But it was broken by #7447. Re-alias `create` to `insert` for fixing it.
* Handle specified schemas when removing a Postgres indexGrey Baker2015-12-181-3/+16
|
* Support passing the schema name prefix to `conenction.indexes`Grey Baker2015-12-171-9/+12
| | | | | | | Support passing the schema name as a prefix to table name in `ConnectionAdapters::SchemaStatements#indexes`. Previously the prefix would be considered a full part of the index name, and only the schema in the current search path would be considered.
* Deprecate `#table_exists?`, `#tables` and passing arguments to `#talbes`yui-knk2015-11-091-1/+16
| | | | | | | | | | Reported on #21509, how views is treated by `#tables` are differ by each adapters. To fix this different behavior, after Rails 5.0 is released, deprecate `#tables`. And `#table_exists?` would check both tables and views. To make their behavior consistent with `#tables`, after Rails 5.0 is released, deprecate `#table_exists?`.
* Do not cache prepared statements that are unlikely to have cache hitsSean Griffin2015-10-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this commit, Rails makes no differentiation between whether a query uses bind parameters, and whether or not we cache that query as a prepared statement. This leads to the cache populating extremely fast in some cases, with the statements never being reused. In particular, the two problematic cases are `where(foo: [1, 2, 3])` and `where("foo = ?", 1)`. In both cases we'll end up quoting the values rather than using a bind param, causing a cache entry for every value ever used in that query. It was noted that we can probably eventually change `where("foo = ?", 1)` to use a bind param, which would resolve that case. Additionally, on PG we can change our generated query to be `WHERE foo = ANY($1)`, and pass an array for the bind param. I hope to accomplish both in the future. For SQLite and MySQL, we still end up preparing the statements anyway, we just don't cache it. The statement will be cleaned up after it is executed. On postgres, we skip the prepare step entirely, as an API is provided to execute with bind params without preparing the statement. I'm not 100% happy on the way this ended up being structured. I was hoping to use a decorator on the visitor, rather than mixing a module into the object, but the way Arel has it's visitor pattern set up makes it very difficult to extend without inheritance. I'd like to remove the duplication from the various places that are extending it, but that'll require a larger restructuring of that initialization logic. I'm going to take another look at the structure of it soon. This changes the signature of one of the adapter's internals, and will require downstream changes from third party adapters. I'm not too worried about this, as worst case they can simply add the parameter and always ignore it, and just keep their previous behavior. Fixes #21992.
* Move the methods for schema dumping into `{mysql,postgresql}/schema_dumper.rb`Ryuta Kamizono2015-10-131-0/+54
| | | | | Current master branch includes many schema dumping improvements. It extract these features to the appropriate files.
* Wrong usage of 'a' in docs fixed [ci skip]Mehmet Emin İNAÇ2015-10-031-1/+1
|
* Merge pull request #20317Sean Griffin2015-09-231-11/+7
|\ | | | | | | | | AR: take precision into count when assigning a value to timestamp attribute
| * Fixed taking precision into count when assigning a value to timestamp attributeBogdan Gusiev2015-09-231-11/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Timestamp column can have less precision than ruby timestamp In result in how big a fraction of a second can be stored in the database. m = Model.create! m.created_at.usec == m.reload.created_at.usec # => false # due to different seconds precision in Time.now and database column If the precision is low enough, (mysql default is 0, so it is always low enough by default) the value changes when model is reloaded from the database. This patch fixes that issue ensuring that any timestamp assigned as an attribute is converted to column precision under the attribute.
* | introduce `conn.data_source_exists?` and `conn.data_sources`.Yves Senn2015-09-221-0/+11
|/ | | | | | | | | | | | | | | | | These new methods are used from the Active Record model layer to determine which relations are viable to back a model. These new methods allow us to change `conn.tables` in the future to only return tables and no views. Same for `conn.table_exists?`. The goal is to provide the following introspection methods on the connection: * `tables` * `table_exists?` * `views` * `view_exists?` * `data_sources` (views + tables) * `data_source_exists?` (views + tables)
* Merge pull request #21609 from kamipo/do_not_dump_view_as_tableJeremy Daer2015-09-191-0/+24
|\ | | | | | | Do not dump a view as a table in sqlite3, mysql and mysql2 adapters
| * Add `#views` and `#view_exists?` methods on connection adaptersRyuta Kamizono2015-09-131-0/+24
| |
* | Correctly dump composite primary keyRyuta Kamizono2015-09-201-11/+13
|/ | | | | | | | | Example: create_table :barcodes, primary_key: ["region", "code"] do |t| t.string :region t.integer :code end
* Correct query for PostgreSQL 8.2Matthew Draper2015-09-081-1/+1
| | | | Generic cast-to-text was only added in 8.3.
* Fix test failures from premature merge of #21317Matthew Draper2015-09-071-4/+8
| | | | | | | | Apparently I managed to forget how similar the "tests passing" and "no status reported" merge indicators look. Note that the previous `stubs` in test_add_index wasn't working: the method was still called, and just happened to return false.
* Support dropping indexes concurrently in PostgresGrey Baker2015-09-051-2/+9
| | | | | See http://www.postgresql.org/docs/9.4/static/sql-dropindex.html for more details.
* pg, `create_schema`, `drop_schema` and `rename_table` quote schema name.Yves Senn2015-08-282-3/+8
| | | | | | | | Closes #21418. Previously schema names were not quoted. This leads to issues when a schema names contains a ".". Methods in `schema_statements.rb` should quote user input.
* pg docs, `connection.tables` does not use the `name` argument.Yves Senn2015-08-281-1/+1
| | | | | | | | | | | | [ci skip] Currently the `#tables` method does not make use of the `name` argument and always returns all the tables in the schema search path. However the docs suggest different behavior. While we should porbably adjust the implementation to provide this behavior, let's make the docs right for now (also for `4-2-stable`) and then implement the behavior on `master`.
* PostgreSQL, add `:if_exists` to `#drop_schema`.Yves Senn2015-08-281-2/+2
|
* JSON is still an adapter specific type.Sean Griffin2015-08-213-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several changes were made in #21110 which I am strongly opposed to. (this is what I get for going on vacation. :trollface:) No type should be introduced into the generic `ActiveRecord::Type` namespace, and *certainly* should not be registered into the registry unconstrained unless it is supported by *all* adapters (which basically means that it was specified in the ANSI SQL standard). I do not think `# :nodoc:` ing the type is sufficient, as it still makes the code of Rails itself very unclear as to what the role of that class is. While I would argue that this shouldn't even be a super class, and that MySql and PG's JSON types are only superficially duplicated (they might look the same but will change for different reasons in the future). However, I don't feel strongly enough about it as a point of contention (and the biggest cost of harming the blameability has already occured), so I simply moved the superclass into a namespace where its role is absolutely clear. After this change, `attribute :foo, :json` will once again work with MySQL and PG, but not with Sqlite3 or any third party adapters. Unresolved questions -------------------- The types that and adapter publishes (at least those are unique to that adapter, and not adding additional behavior like `MysqlString` should probably be part of the adapter's public API. Should we standardize the namespace for these, and document them?
* Add a native JSON data type support in MySQLRyuta Kamizono2015-08-183-37/+1
| | | | | | | | | | As of MySQL 5.7.8, MySQL supports a native JSON data type. Example: create_table :json_data_type do |t| t.json :settings end
* Merge pull request #20459Sean Griffin2015-08-061-0/+24
|\
| * Add missing data types for ActiveRecord migrationsMehmet Emin İNAÇ2015-06-081-0/+24
| |
* | Freeze string literals when not mutated.schneems2015-07-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I wrote a utility that helps find areas where you could optimize your program using a frozen string instead of a string literal, it's called [let_it_go](https://github.com/schneems/let_it_go). After going through the output and adding `.freeze` I was able to eliminate the creation of 1,114 string objects on EVERY request to [codetriage](codetriage.com). How does this impact execution? To look at memory: ```ruby require 'get_process_mem' mem = GetProcessMem.new GC.start GC.disable 1_114.times { " " } before = mem.mb after = mem.mb GC.enable puts "Diff: #{after - before} mb" ``` Creating 1,114 string objects results in `Diff: 0.03125 mb` of RAM allocated on every request. Or 1mb every 32 requests. To look at raw speed: ```ruby require 'benchmark/ips' number_of_objects_reduced = 1_114 Benchmark.ips do |x| x.report("freeze") { number_of_objects_reduced.times { " ".freeze } } x.report("no-freeze") { number_of_objects_reduced.times { " " } } end ``` We get the results ``` Calculating ------------------------------------- freeze 1.428k i/100ms no-freeze 609.000 i/100ms ------------------------------------------------- freeze 14.363k (± 8.5%) i/s - 71.400k no-freeze 6.084k (± 8.1%) i/s - 30.450k ``` Now we can do some maths: ```ruby ips = 6_226k # iterations / 1 second call_time_before = 1.0 / ips # seconds per iteration ips = 15_254 # iterations / 1 second call_time_after = 1.0 / ips # seconds per iteration diff = call_time_before - call_time_after number_of_objects_reduced * diff * 100 # => 0.4530373333993266 miliseconds saved per request ``` So we're shaving off 1 second of execution time for every 220 requests. Is this going to be an insane speed boost to any Rails app: nope. Should we merge it: yep. p.s. If you know of a method call that doesn't modify a string input such as [String#gsub](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37) please [give me a pull request to the appropriate file](https://github.com/schneems/let_it_go/blob/b0e2da69f0cca87ab581022baa43291cdf48638c/lib/let_it_go/core_ext/string.rb#L37), or open an issue in LetItGo so we can track and freeze more strings. Keep those strings Frozen ![](https://www.dropbox.com/s/z4dj9fdsv213r4v/let-it-go.gif?dl=1)
* | Add reversible syntax for change_column_defaultPrem Sichanugrist2015-06-261-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | Passing `:from` and `:to` to `change_column_default` makes this command reversible as user has defined its previous state. So, instead of having the migration command as: change_column_default(:posts, :state, "draft") They can write it as: change_column_default(:posts, :state, from: nil, to: "draft")
* | Correctly handle array columns with defaults in the schema dumperSean Griffin2015-06-111-0/+5
|/ | | | | | | | | If the subtype provides custom schema dumping behavior, we need to defer to it. We purposely choose not to handle any values other than an array (which technically should only ever be `nil`, but I'd rather code defensively here). Fixes #20515.
* Return a `Point` object from the PG Point typeSean Griffin2015-06-052-0/+51
| | | | | | | | | | | | | | | | | | | 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
* Fixed typos in guidemanish-shrivastava2015-06-011-1/+1
|
* Avoid the heredoc in one line queries and simple queriesRyuta Kamizono2015-05-191-20/+5
| | | | Related with #20028.
* Fix `serial?` with quoted sequence nameRyuta Kamizono2015-05-181-1/+2
|
* :nodoc: postgresql add_columnTony Miller2015-05-131-3/+1
|
* :nodoc: rename_column in postgresql/schema_statements.rbTony Miller2015-05-081-1/+1
| | | | | Its already doc'ed in activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb
* Use `select_value` for avoid `ActiveRecord::Result` instance creatingRyuta Kamizono2015-05-051-21/+16
| | | | | `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-2/+12
| | | | | | | | | 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
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-05 16:42:56 +0000