| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
Bring type casting behavior of hstore/json in line with serialized
|
| |
| |
| |
| |
| | |
`@raw_attributes` should not contain the type-cast, mutable version of
the value.
|
|/
|
|
| |
BC era year is (astronomical year + 1) and starts from 1 BC.
|
|\
| |
| | |
Refactor quoting of binary data to not be based on the column type
|
| | |
|
| | |
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
|
|
| |
This inlines casting for the most obvious types. The rest will
follow eventually. I need to put some tests in place, to make sure
that the inlining is not causing regressions.
/cc @sgrif
|
|
|
|
|
|
|
| |
This removes the case statement in `SchemaDumper` and gives every `Type`
the possibility to control the SchemaDumper default value output.
/cc @sgrif
|
|
|
|
|
| |
This is an intermediate solution. It is related to the refactoring @sgrif
is making and will change in the future.
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Fixed #columns_for_distinct of postgresql adapter
Conflicts:
activerecord/CHANGELOG.md
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
Many of the methods defined in `AttributeMethods::Serialization` can be
refactored onto this type as well, but this is a reasonable small step.
Removes the `Type` class, and the need for `decorate_columns` to handle
serialized types.
|
| |
| |
| |
| |
| |
| | |
- Create a consistent API across adapters for building new columns
- Use it for custom properties so we don't get `UndefinedMethodError`s
in stuff I'm implementing elsewhere.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The solution presented in this patch is not efficient. We should replace it
in the near future. The following needs to be worked out:
* Is `@attributes` storing the Ruby or SQL representation?
* `cacheable_column?` is broken but `hstore` and `json` rely on that behavior
Refs #15369.
/cc @sgrif @rafaelfranca
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This mirrors the layout of abstract adapter and puts the definitions
inside the `PostgreSQL` namespace (no longer under the adapter namespace).
/cc @kares
|
|\ \
| | |
| | | |
Move parsing of PG sql strings for defaults out of column
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| | |
Columns and injected types no longer have any conditionals based on the
format of SQL type strings! Hooray!
|
| |
| |
| |
| |
| |
| | |
Ideally types will be usable without having to specify a sql type
string, so we should keep the information related to parsing them on the
adapter or another object.
|
| | |
|
|\ \
| | |
| | | |
Use the generic type map for all PG type registrations
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
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 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
|
| | |
|
|\ \
| | |
| | | |
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.
|
|/ /
| |
| |
| |
| | |
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.
|
| |
| |
| |
| | |
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`.
|
| | |
|