| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
This basically reverts 9d4f79d3d394edb74fa2192e5d9ad7b09ce50c6d
|
| |
|
|
|
|
| |
We already have database agnostic `Type::Json` since #29220.
|
| |
|
|
|
|
| |
Closes #27980
|
|
|
|
|
|
|
|
|
|
| |
There are some minor changes to the point type as I had forgotten that
this will affect the behavior of `t.point` in migrations and the schema
dumper so we need to handle those as well.
I'll say this again so I can convince myself to come up with a better
structure... TYPES SHOULD NOT CARE ABOUT SCHEMA DUMPING AND WE NEED TO
BETTER SEPARATE THESE.
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
| |
|
| |
|
| |
|
| |
|