| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| | |
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`.
|
| |
|
|
|
|
|
| |
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.
|
|\ |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
| |
The PG Adapter should use `:datetime` consistently instead of mapping
mispellings to `:timestamp`.
See #14513
|
|
|
|
|
| |
whether to exec with cache for Postgresql adapter
Reduces creating unused objects, with the most dramatic reduction in select_values which used to map(&:first) an array of single element arrays.
|
|
|
|
| |
uuid_generate function was not being quoted.
|
|
|
|
| |
[Yves Senn & Matthew Draper]
|
|
|
|
|
|
|
|
|
|
| |
In our normal usage, it's rare for this to make a difference... but is
more technically correct.
As well as a spec that proves this is a good idea, let's also add a more
sane-looking one that just covers basic to_sql functionality. There
aren't many places where we actually use escape_bytea, but that's one
that won't be going away.
|
| |
|
|
|
|
|
| |
Expand the query used in #table_exists? to include materialized views in the
kinds of relations it searches.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
We have `connection_adapters/column.rb` so it's easier to remember
that the column in in a separate file.
|
|
|
|
|
|
|
|
|
|
|
| |
The pk_an_sequence_for query previously joined against pg_class's oid
for rows in pg_depend, but pg_depend's objid may point to other system
tables, such as pg_attrdef. If a row in one of those other tables
coincidentally has the same oid as an (unrelated) sequence, that
sequence name may be returned instead of the real one.
This ensures that only the pg_depend entries pointing to pg_class are
considered.
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| | |
Conflicts:
actionview/CHANGELOG.md
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| |
| | |
Thanks Godfrey Chan for reporting this!
Fixes: CVE-2014-0080
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We didn't have enough encoding for the wire protocol to store an array
of hstore types. So, further encode any hstore that is an array member.
Whilst we're here, ensure it's an HashWithIndifferentAccess being
returned, to be consistent with other serialized forms, and add testing
for arrays of hstore.
So now the following migration:
enable_extension "hstore"
create_table :servers do |t|
t.string :name
t.hstore :interfaces, array: true
end
produces a model that can used like this, to store an array of hashes:
server = Server.create(name: "server01", interfaces: [
{ name: "bge0", ipv4: "192.0.2.2", state: "up" },
{ name: "de0", state: "disabled", by: "misha" },
{ name: "fe0", state: "up" },
])
More at http://inopinatus.org/2013/07/12/using-arrays-of-hstore-with-rails-4/
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
PostgreSQL implementation of SchemaStatements#index_name_exists?
Conflicts:
activerecord/CHANGELOG.md
|
| | | |
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This was a common pattern:
```
query = author.posts.select(:title)
connection.select_one(query)
```
However `.select` returns a ActiveRecord::AssociationRelation, which has
the bind information, so we can use that to get the right sql query.
Also fix select_rows on postgress and sqlite3 that were not using the binds
[fixes #7538]
[fixes #12017]
[related #13731]
[related #12056]
|
|/
|
|
| |
Closes #13444
|
| |
|