| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
Determining things like precision and scale in postgresql will require
the given blocks to take additional arguments besides the OID.
- Adds the ability to handle additional arguments to `TypeMap`
- Passes the column type to blocks when looking up PG types
|
|\
| |
| | |
Move extract_scale to decimal type
|
| |
| |
| |
| |
| |
| | |
The only type that has a scale is decimal. There's a special case where
decimal columns with 0 scale are type cast to integers if the scale is
not specified. Appears to only affect schema dumping.
|
|\ \
| | |
| | | |
Move PG OID types to their own files
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| |
|
| |
|
|\
| |
| | |
Inline typecasting helpers from Column to the appropriate types
|
| | |
|
|\ \
| | |
| | | |
Use the generic type map for PostgreSQL OID registrations
|
| |/ |
|
|/ |
|
| |
|
|\
| |
| | |
Replace `type_cast` case statement with delegation
|
| |
| |
| |
| |
| |
| |
| |
| | |
All subclasses of column were now delegating `type_cast` to their
injected type object. We can remove the overriding methods, and
generalize it on the `Column` class itself. This also enabled us to
remove several column classes completely, as they no longer had any
meaningful behavior of their own.
|
|\ \
| | |
| | | |
Have Postgres OID types inherit from general types
|
| | |
| | |
| | |
| | |
| | | |
Using general types where possible. Several more can go away once
infinity gets figured out.
|
| |/
|/| |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `:timestamp` type for columns is unused. All database adapters treat
them as the same database type. All code in `ActiveRecord` which changes
its behavior based on the column's type acts the same in both cases.
However, when the type is passed to code that checks for the `:datetime`
type, but not `:timestamp` (such as XML serialization), the result is
unexpected behavior.
Existing schema definitions will continue to work, and the `timestamp`
type is transparently aliased to `datetime`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Make `:index` in migrations work with all column types
|
| | |
|
| |
| |
| |
| | |
Partial revert of c0bfc3f412834ffe8327a15ae3a46602cc28e425
|
| | |
|
|\ \
| |/
|/| |
PostgreSQL timestamps should always be datetimes
|
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
Part of #15134. In order to perform typecasting polymorphically, we need
to add another argument to the constructor. The order was chosen to
match the `oid_type` on `PostgreSQLColumn`.
|
|/ |
|
|
|
|
| |
double limits
|
| |
|
|
|
|
|
| |
They should not be used on people application so they should not be
present on the API documentation.
|
|
|
|
| |
redundant
|
| |
|
| |
|
|
|
| |
... 'shared' OID, ArrayParser and Cast helpers, also re-arranged Column's dependencies
|
|\
| |
| | |
[postgres] include PgArrayParser directly
|
| |
| |
| |
| | |
if not found
|
|/ |
|
| |
|
|
|
|
| |
Closes #10802.
|
|
|
|
| |
Before this patch `Infinity`, `-Infinity` and `Nan` were read as `0`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In #10410 it was noted that you can no longer create PK's with the
type of bigserial in PostgreSQL in 4.0.0.rc1. This is mostly
because the newer adapter is checking for column type with the
id column instead of just letting it pass through like it did
before.
Side effects:
You may just create a PK column of a type that you really don't
want to be your PK. As far as I can tell this was allowed in 3.2.X
and perhaps an exception should be raised if you try and do
something extremely dumb.
|
|\ |
|
| | |
|
| | |
|