| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
[Philippe Creux, Chris Teague]
|
| |
|
| |
|
|
|
|
|
|
|
| |
We're going to want all of the benefits of the type map object for
registrations, including block registration and real aliasing. Moves
type name registrations to the adapter, and aliases the OIDs to the
named types
|
|
|
|
|
|
|
| |
As we promote these classes to first class concepts, these classes are
starting to gain enough behavior to warrant being moved into their own
files. Many of them will become quite large as we move additional
behavior to the type objects.
|
|
|
|
|
|
|
| |
- `extract_precision`, `extract_limit`, and `extract_default` probably need to follow.
- would be good to remove the delegation `Column#extract_scale`.
/cc @sgrif
|
|\
| |
| | |
Use the generic type map for PostgreSQL OID registrations
|
| | |
|
|/ |
|
|
|
|
|
| |
Using general types where possible. Several more can go away once
infinity gets figured out.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The decision to wrap type registrations in a proc was made for two
reasons.
1. Some cases need to make an additional decision based on the type
(e.g. a `Decimal` with a 0 scale)
2. Aliased types are automatically updated if they type they point to is
updated later. If a user or another adapter decides to change the
object used for `decimal` columns, `numeric`, and `number` will
automatically point to the new type, without having to track what
types are aliased explicitly.
Everything else here should be pretty straightforward. PostgreSQL ranges
had to change slightly, since the `simplified_type` method is gone.
|
| |
|
|
|
|
|
|
|
|
| |
The current behavior is that they are treated as `datetime` normally,
but if they are part of an array, they are treated as `timestamp`. The
only place that seems to be impacted by this is schema dumping, which
shouldn't matter since `t.datetime` and `t.timestamp` are equivalent in
the `PostgreSQL` adapter, anyway.
|
|
|
| |
... 'shared' OID, ArrayParser and Cast helpers, also re-arranged Column's dependencies
|
| |
|
|
|
|
| |
Closes #10802.
|
|
|
|
| |
Before this patch `Infinity`, `-Infinity` and `Nan` were read as `0`.
|
|
|
|
|
|
|
| |
The PG Adapter should use `:datetime` consistently instead of mapping
mispellings to `:timestamp`.
See #14513
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I ran the whole test suite and compared the old to the new types.
Following is the list of types that did change with this patch:
```
DIFFERENT TYPE FOR mood: NEW: enum, BEFORE:
DIFFERENT TYPE FOR floatrange: NEW: floatrange, BEFORE: float
```
The `floatrange` is a custom type. The old type `float` was simply a coincidence
form the name `floatrange` and our type-guessing.
|
|
|
|
| |
citext makes it possible to use AR Hash finders for case-insensitive matching as sql UPPER/LOWER functions are not needed.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Ruby Range object does not support excluding beginnings.
We currently support excluding beginnings for some subtypes using
manually by incrementing them (now using the `#succ` method).
This is approach is flawed as it's not equal to an excluding beginning.
This commit deprecates the current support for excluding beginnings.
It also raises an `ArgumentError` for subtypes that do not implement the `succ`
method.
This is a temporary solution to get rid of the broken state. We might still
add complete support for excluding beginnings afterwards. (Probably with a
new `PGRange` object, which acts like a `Range` but has excluding beginnings.
|
|
|
|
|
|
|
|
| |
This gets AR working with custom defined range types. It also
removes the need for subtype specific branches in `OID::Range`.
This expands the interface of all `OID` types with the `infinity` method.
It's responsible to provide a value for positive and negative infinity.
|
| |
|
| |
|
|
|
|
| |
See also commit 5ac2341fab689344991b2a4817bd2bc8b3edac9d
|
|
|
|
|
|
| |
This is necessary because as of 5ac2341 `hstore` columns are always stored
as `Hash` with `String` keys. `ActiveRecord::Store` expected the attribute to
be an instance of `HashWithIndifferentAccess`, which led to the bug.
|
|
|
|
| |
Closes #11899.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In an AR model a timestamptz attribute would return a ruby string and AR
tests did not check for any type casting. Previous tests would pass
only because an assert_equal was being used on a Time.utc object, which
will parse the right side of the eq to a valid Time instance for
comparision.
switch to test instance of Time instead of ActiveSupport::TimeWithZone
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Having column related schema dumper code in the AbstractAdapter. The
code remains the same, but by placing it in the AbstractAdapter, we can
then overwrite it with Adapter specific methods that will help with
Adapter specific data types.
The goal of moving this code here is to create a new migration key for
PostgreSQL's array type. Since any datatype can be an array, the goal is
to have ':array => true' as a migration option, turning the datatype
into an array. I've implemented this in postgres_ext, the syntax is
shown here: https://github.com/dockyard/postgres_ext#arrays
Adds array migration support
Adds array_test.rb outlining the test cases for array data type
Adds pg_array_parser to Gemfile for testing
Adds pg_array_parser to postgresql_adapter (unused in this commit)
Adds schema dump support for arrays
Adds postgres array type casting support
Updates changelog, adds note for inet and cidr support, which I forgot to add before
Removing debugger, Adds pg_array_parser to JRuby platform
Removes pg_array_parser requirement, creates ArrayParser module used by
PostgreSQLAdapter
|
|
|
|
|
|
|
|
|
| |
This implements the support to encode/decode JSON
data to/from database and creating columns of type
JSON using a native type [1] supported by PostgreSQL
from version 9.2.
[1] http://www.postgresql.org/docs/9.2/static/datatype-json.html
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* joelhoffman-postgres_schema_builder:
Also support writing the hstore back to the database
Hstore values are all strings
string_to_hstore / hstore_to_string, serializing
don't test schema where hstore not installed
schema dumper tests for hstore
Additional hstore tests, supporting null values, better compliance with postgres docs
add hstore to postgres native types and defaults
Conflicts:
activerecord/lib/active_record/connection_adapters/postgresql_adapter.rb
|