in the new 'variables:' hash in each database config section in database.yml. The key-value pairs of this hash will be sent in a 'SET key = value, ...' query on new database connections. The configure_connection methods from mysql and mysql2 into are consolidated into the abstract_mysql base class.
According to postgreSQL documentation: (http://www.postgresql.org/docs/8.2/static/catalog-pg-attrdef.html) we should not be using 'adsrc' field because this field is unaware of outside changes that could affect the way that default values are represented. Thus, I changed the queries to use "pg_get_expr(adbin, adrelid)" instead of the historical "adsrc" field.
PostgreSQL adapter properly parses default values when using multiple schemas and domains. When using domains across schemas, PostgresSQL prefixes the type of the default value with the name of the schema where that type (or domain) is. For example, this query: ``` SELECT a.attname, d.adsrc FROM pg_attribute a LEFT JOIN pg_attrdef d ON a.attrelid = d.adrelid AND a.attnum = d.adnum WHERE a.attrelid = "defaults"'::regclass AND a.attnum > 0 AND NOT a.attisdropped ORDER BY a.attnum; ``` could return something like "'<default_value>'::pg_catalog.text" or "(''<default_value>'::pg_catalog.text)::text" for the text columns with defaults. I modified the regexp used to parse this value so that it ignores anything between ':: and \b(?:character varying|bpchar|text), and it allows to have optional parens like in the above second example.
If your database supports setting the isolation level for a transaction, you can set it like so: Post.transaction(isolation: :serializable) do # ... end Valid isolation levels are: * `:read_uncommitted` * `:read_committed` * `:repeatable_read` * `:serializable` You should consult the documentation for your database to understand the semantics of these different levels: * http://www.postgresql.org/docs/9.1/static/transaction-iso.html * https://dev.mysql.com/doc/refman/5.0/en/set-transaction.html An `ActiveRecord::TransactionIsolationError` will be raised if: * The adapter does not support setting the isolation level * You are joining an existing open transaction * You are creating a nested (savepoint) transaction The mysql, mysql2 and postgresql adapters support setting the transaction isolation level. However, support is disabled for mysql versions below 5, because they are affected by a bug (http://bugs.mysql.com/bug.php?id=39170) which means the isolation level gets persisted outside the transaction.
This avoids us having to manually increment and decrement it.
Having column related schema dumper code in the AbstractAdapter. The code remains the same, but by placing it in the AbstractAdapter, we can then overwrite it with Adapter specific methods that will help with Adapter specific data types. The goal of moving this code here is to create a new migration key for PostgreSQL's array type. Since any datatype can be an array, the goal is to have ':array => true' as a migration option, turning the datatype into an array. I've implemented this in postgres_ext, the syntax is shown here: https://github.com/dockyard/postgres_ext#arrays Adds array migration support Adds array_test.rb outlining the test cases for array data type Adds pg_array_parser to Gemfile for testing Adds pg_array_parser to postgresql_adapter (unused in this commit) Adds schema dump support for arrays Adds postgres array type casting support Updates changelog, adds note for inet and cidr support, which I forgot to add before Removing debugger, Adds pg_array_parser to JRuby platform Removes pg_array_parser requirement, creates ArrayParser module used by PostgreSQLAdapter
This implements the support to encode/decode JSON data to/from database and creating columns of type JSON using a native type  supported by PostgreSQL from version 9.2.  http://www.postgresql.org/docs/9.2/static/datatype-json.html
Exception.result is nil when attempting a query after PostgreSQL disconnect, resulting in new exception: NoMethodError: undefined method `error_field' for nil:NilClass
PQstatus doesn't properly test if future operations will succeed. A PQping function is added to libpq in PostgreSQL 9.1, but if we rely on it, everyone on earlier versions of Postgres is out of luck, and the pg gem wouldn't have the 'fix' until the next release. Thanks to @cbrecabarren and @ged for handling all the dirty details. Closes #3392.