| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
[Yves Senn & Matthew Draper]
|
|
|
|
| |
[Yves Senn & Matthew Draper]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
& Yves Senn]
There is no reason for the PG adapter to have a default limit of 255 on :string
columns. See this snippet from the PG docs:
Tip: There is no performance difference among these three types, apart
from increased storage space when using the blank-padded type, and a
few extra CPU cycles to check the length when storing into a
length-constrained column. While character(n) has performance
advantages in some other database systems, there is no such advantage
in PostgreSQL; in fact character(n) is usually the slowest of the
three because of its additional storage costs. In most situations text
or character varying should be used instead.
|
|
|
|
|
| |
Expand the query used in #table_exists? to include materialized views in the
kinds of relations it searches.
|
|
|
|
|
|
|
|
|
|
|
| |
* Clarify what the situation is and what to do.
* Advise loading schema using `rake db:setup` instead of migrating.
* Use a rescue in the initializer rather than extending the error
message in-place.
* Preserve the original backtrace of other errors by using `raise`
rather than raising again with `raise error`.
References 0ec45cd15d0a2f5aebc75e23d841b6c12f3ba763
|
|
|
|
|
| |
This is a follow-up fix to f7a6b115fea9f675190a79b701c7034214678f19 and
06082f66d541e581110406bbac3bc395bace3f86
|
| |
|
|
|
|
|
|
|
| |
This patch registers custom domains in our OID-type_map.
They will behave exactly as the type specified by `pg_type.typbasetype`.
/cc @matthewd
|
|
|
|
|
| |
We have `connection_adapters/column.rb` so it's easier to remember
that the column in in a separate file.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
.. not a general timeout.
Now, if a thread checks out a connection then dies, we can immediately
recover that connection and re-use it.
This should alleviate the pool exhaustion discussed in #12867. More
importantly, it entirely avoids the potential issues of the reaper
attempting to check whether connections are still active: as long as the
owning thread is alive, the connection is its business alone.
As a no-op reap is now trivial (only entails checking a thread status
per connection), we can also perform one in-line any time we decide to
sleep for a connection.
|
|
|
|
| |
It wasn't doing anything beyond clearing the statement cache.
|
| |
|
|
|
|
| |
citext makes it possible to use AR Hash finders for case-insensitive matching as sql UPPER/LOWER functions are not needed.
|
| |
|
|
|
|
|
| |
- unused variable in PG Adapter.
- Ambiguous argument warning from range_test for use - to + Infinity range without brackets.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
- Earlier, change_table was creating database-agnostic object.
- After this change, it will create correct object based on current
database adapter.
- This will ensure that create_table and change_table will get same objects.
- This makes update_table_definition method public and nodoc.
- Fixes #13577 and #13503
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code uses these checks in several places to know what to do with a
particular column, for instance AR attribute query methods has a branch
like this:
if column.number?
!value.zero?
end
This should never be true for array columns, since it would be the same
as running [].zero?, which results in a NoMethodError exception.
Fixing this by ensuring that array columns in PostgreSQL never return
true for number?/text? checks.
Since most of the array support was based on the postgres_ext lib, it's
worth noting it does the same thing for numeric array columns too:
https://github.com/dockyard/postgres_ext/blob/v1.0.0/lib/postgres_ext/active_record/connection_adapters/postgres_adapter.rb#L72
This extended the same logic for text columns to ensure consistency.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently if you attempt to use a database that does not exist you get an error:
```
PG::ConnectionBad FATAL: database "db_error" does not exist
```
The solution is easy, create and migrate your database however new developers may not know these commands by memory. Instead of requiring the developer to search for a solution, tell them how to fix the problem in the error message:
```
ActiveRecord::NoDatabase: FATAL: database "db_error" does not exist
Run `$ bin/rake db:create db:migrate` to create your database
```
Active Record should not know about `rake db:migrate` so this additional information needs to come from the railtie. Potential alternative implementation suggestions are welcome.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, executing an insert SQL in PostgreSQL with a command like this:
insert into articles(
number)
values(
5152
)
would not work because the adapter was unable to extract the correct articles table name.
|
|
|
|
|
| |
also override drop_table in AbstractMySQLAdapter to properly drop
temporary tables without committing the transaction
|
| |
|
| |
|
|
|
| |
Drop some comments that document the implementation rather than the interface.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The log output used to be confusing in situation where type casting has
"unexpected" effects. For example when finding records with a `String`.
BEFORE:
irb(main):002:0> Event.find("im-no-integer")
D, [2013-11-09T11:10:28.998857 #1706] DEBUG -- : Event Load (4.5ms) SELECT "events".* FROM "events" WHERE "events"."id" = $1 LIMIT 1 [["id", "im-no-integer"]]
AFTER:
irb(main):002:0> Event.find("im-no-integer")
D, [2013-11-09T11:10:28.998857 #1706] DEBUG -- : Event Load (4.5ms) SELECT "events".* FROM "events" WHERE "events"."id" = $1 LIMIT 1 [["id", 0]]
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
This is causing every default value in PostreSQL database to being
handled as default function.
Fixes #12581
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
This is to be consistent with the way the mysql2 adapter times queries
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Dump UUID default functions to schema.rb [2nd version]. Fixes #10751.
Conflicts:
activerecord/CHANGELOG.md
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the adapter is with prepared statement disabled and the binds array
is not empty the connection adapter will try to set the binds values and
will fail. Now we are checking if the adapter has the prepared statement
disabled.
Fixes #12023
|
| | |
|
|/
|
|
| |
Closes: #11706
|
|
|
|
|
|
|
|
|
|
| |
PostgreSQL escapes single quotes by using an additional single quote.
When Rails queries the column information, PostgreSQL returns the
default values with the escaped single quotes.
#extract_value_from_default now converts these to one single quote each.
Fixes #10881.
|
|
|
|
| |
since 9.1.
|
|
|
|
|
|
|
| |
patricksrobertson/bigserial_id_not_identifying_pk"
This reverts commit 3043d45eefc3776d5f3a9e7d212a01f99d869ef8, reversing
changes made to ca0275d36b395631725c4583db5a45c06443fdb9.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
It is new in PostgreSQL-9.2 .
|