aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/connection_adapters/postgresql/oid
Commit message (Collapse)AuthorAgeFilesLines
...
* 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.
* Correct query for PostgreSQL 8.2Matthew Draper2015-09-081-1/+1
| | | | Generic cast-to-text was only added in 8.3.
* JSON is still an adapter specific type.Sean Griffin2015-08-212-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-182-36/+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
* 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-051-0/+50
| | | | | | | | | | | | | | | | | | | 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
|
* Reduce memory usage when loading types in PGSean Griffin2015-03-291-4/+16
| | | | | | | | | | | | | 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-50/+6
| | | | This obsoletes the ruby based implementations.
* PostgreSQL, Fix OID based type casts in C for primitive types.Lars Kanis2015-03-251-1/+1
| | | | | | | | | | 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.
* Delegate limit to subtypewallerjake2015-03-211-1/+1
| | | | | | | | | | As described here https://github.com/rails/rails/issues/19420. When using the Postgres BigInt[] field type the big int value was not being translated into schema.rb. This caused the field to become just a regular integer field when building off of schema.rb. This fix will address this by delegating the limit from the subtype to the Array type. https://github.com/rails/rails/issues/19420
* Don't cast nil to string in pg enumsSean Griffin2015-03-191-1/+3
| | | | Fixes #19389.
* Rm `Type#type_cast`Sean Griffin2015-02-176-8/+8
| | | | | | | | | This helper no longer makes sense as a separate method. Instead I'll just have `deserialize` call `cast` by default. This led to a random infinite loop in the `JSON` pg type, when it called `super` from `deserialize`. Not really a great way to fix that other than not calling super, or continuing to have the separate method, which makes the public API differ from what we say it is.
* `type_cast_from_user` -> `cast`Sean Griffin2015-02-171-2/+2
|
* `type_cast_for_database` -> `serialize`Sean Griffin2015-02-1710-12/+12
|
* `Type#type_cast_from_database` -> `Type#deserialize`Sean Griffin2015-02-177-8/+8
|
* Remove an unused option that I didn't mean to commit [ci skip]Sean Griffin2015-02-111-2/+1
|
* Remove most PG specific type subclassesSean Griffin2015-02-119-74/+14
| | | | | | | | | 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.
* Refactor microsecond precision to be database agnosticSean Griffin2015-02-101-9/+0
| | | | | | | | | | The various databases don't actually need significantly different handling for this behavior, and they can achieve it without knowing about the type of the object. The old implementation was returning a string, which will cause problems such as breaking TZ aware attributes, and making it impossible for the adapters to supply their logic for time objects.
* Fix rounding problem for PostgreSQL timestamp columnRyuta Kamizono2015-02-081-0/+9
| | | | | If timestamp column have the precision, it need to format according to the precision of timestamp column.
* rm `Type#text?`Sean Griffin2015-02-071-4/+0
| | | | | | | | | | | | | | | | 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.
* Move non-type objects into the `Type::Helpers` namespaceSean Griffin2015-02-074-4/+4
| | | | | | | The type code is actually quite accessible, and I'm planning to encourage people to look at the files in the `type` folder to learn more about how it works. This will help reduce the noise from code that is less about type casting, and more about random AR nonsense.
* Allow a symbol to be passed to `attribute`, in place of a type objectSean Griffin2015-02-062-1/+13
| | | | | | | | | | | | | | | | | | The same is not true of `define_attribute`, which is meant to be the low level no-magic API that sits underneath. The differences between the two APIs are: - `attribute` - Lazy (the attribute will be defined after the schema has loaded) - Allows either a type object or a symbol - `define_attribute` - Runs immediately (might get trampled by schema loading) - Requires a type object This was the last blocker in terms of public interface requirements originally discussed for this feature back in May. All the implementation blockers have been cleared, so this feature is probably ready for release (pending one more look-over by me).
* Don't error when invalid json is assigned to a JSON columnSean Griffin2015-01-211-1/+1
| | | | | | | Keeping with our behavior elsewhere in the system, invalid input is assumed to be `nil`. Fixes #18629.
* Time columns should support time zone aware attributesSean Griffin2015-01-151-1/+1
| | | | | | The types that are affected by `time_zone_aware_attributes` (which is on by default) have been made configurable, in case this is a breaking change for existing applications.
* remove deprecated support for PG ranges with exclusive lower bounds.Yves Senn2015-01-051-10/+1
| | | | addresses https://github.com/rails/rails/commit/91949e48cf41af9f3e4ffba3e5eecf9b0a08bfc3#commitcomment-9144563
* PostgreSQL, Fix change detection caused by wrong data for bytea unescaping.Lars Kanis2014-12-291-0/+1
| | | | | | | | | | This showed up when running BinaryTest#test_load_save with the more restrictive input string handling of pg-0.18.0.pre20141117110243.gem . Bytea values sent to the server are in binary format, but are returned back as escaped text. To fulfill the assumption that type_cast_from_database(type_cast_for_database(binary)) == binary we unescape only, if the value was really received from the server.
* Correctly ignore `case_sensitive` for UUID uniqueness validationSean Griffin2014-12-261-0/+4
| | | | | | | | I think we should deprecate this behavior and just error if you tell us to do a case insensitive comparison for types which are not case sensitive. Partially reverts 35592307 Fixes #18195
* Relax the UUID regexGodfrey Chan2014-12-181-9/+2
| | | | | | | | Apparently PG does not validate against RFC 4122. The intent of the original patch is just to protect against PG errors (which potentially breaks txns, etc) because of bad user input, so we shouldn't try any harder than PG itself. Closes #17931
* Revert to 4.1 behavior for casting PG arraysSean Griffin2014-12-081-0/+3
| | | | | | | | | | The user is able to pass PG string literals in 4.1, and have it converted to an array. This is also possible in 4.2, but it would remain in string form until saving and reloading, which breaks our `attr = save.reload.attr` contract. I think we should deprecate this in 5.0, and only allow array input from user sources. However, this currently constitutes a breaking change to public API that did not go through a deprecation cycle.
* Correctly respect subtypes for PG arrays and rangesSean Griffin2014-12-051-7/+19
| | | | | | | | | | | | | 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
* Remove redundant `to_s` in interpolationclaudiob2014-10-301-3/+3
|
* let's warn with heredocsXavier Noria2014-10-281-4/+7
| | | | | | | | | | | | The current style for warning messages without newlines uses concatenation of string literals with manual trailing spaces where needed. Heredocs have better readability, and with `squish` we can still produce a single line. This is a similar use case to the one that motivated defining `strip_heredoc`, heredocs are super clean.
* Fix description of OID in TypeMapInitializerPrathamesh Sonpatki2014-10-251-1/+1
| | | | [ci skip]
* Avoid using heredoc for user warningsGodfrey Chan2014-08-281-4/+4
| | | | | | | | | | Using heredoc would enforce line wrapping to whatever column width we decided to use in the code, making it difficult for the users to read on some consoles. This does make the source code read slightly worse and a bit more error-prone, but this seems like a fair price to pay since the primary purpose for these messages are for the users to read and the code will not stick around for too long.
* adding the exception RecordNotFound to UUID findJoseLuis Torres2014-08-211-0/+2
|
* Spelling errorsjbsmith862014-08-141-1/+1
|
* Remove unused text? predicate method and delegationCarlos Antonio da Silva2014-08-051-4/+0
| | | | | | | | The method has been removed in 09206716f8695f6b8467f15c1befa5a4c3c10978 (PR #16074), but the delegation was apparently missed, and one instance of the method was added back with the addition of OID::Xml in 336be2bdf7dfa1b31879d0ab27e5f3101b351923 (PR #16072), so we can safely rm both.
* Add support for Postgresql JSONBPhilippe Creux2014-07-241-0/+23
| | | | [Philippe Creux, Chris Teague]
* Treat invalid uuid as nilAbdelkader Boudih2014-07-141-1/+10
|
* Don't rely on the column SQL type for bit string quotingSean Griffin2014-07-111-0/+26
|
* Merge pull request #16072 from sgrif/sg-xml-quotingRafael Mendonça França2014-07-081-0/+32
|\ | | | | Don't rely on the sql type to quote XML columns in PG
| * Don't rely on the sql type to quote XML columns in PGSean Griffin2014-07-061-0/+32
| |
* | Remove the `text?` predicate from the type objectsSean Griffin2014-07-061-4/+0
|/ | | | | | | This was only used for uniqueness validations. The first usage was in conjunction with `limit`. Types which cast to string, but are not considered text cannot have a limit. The second case was only with an explicit `:case_sensitive => true` option given by the user.
* Use the type object for quoting PG RangesSean Griffin2014-07-051-18/+34
|
* Merge pull request #16036 from sgrif/sg-datetime-infinityRafael Mendonça França2014-07-031-0/+1
|\ | | | | Do not rely on the column type when quoting infinity
| * Do not rely on the column type when quoting infinitySean Griffin2014-07-031-0/+1
| |
* | Use the type object for type casting HStore columnsSean Griffin2014-07-031-2/+34
|/
* Use the type object when sending point columns to the DBSean Griffin2014-06-291-1/+7
|
* Use the type object for sending JSON to the databaseSean Griffin2014-06-291-2/+10
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-08 18:19:51 +0000