As of MySQL 5.7.8, MySQL supports a native JSON data type.

Example:

    create_table :json_data_type do |t|
      t.json :settings
    end

As described in the "Follow Coding Conventions" section in our
contribution guide (http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#follow-the-coding-conventions)
we favor `assert_not` over `refute`.

While we don't usually make stylistic changes on it's own I opted to do
it in this case. The reason being that test cases are usually copied as
a starting point for new tests. This results in a spread of `refute` in
files that have been using it already.

this fixes a failing test case

This introduces a deprecation cycle to change the behavior of the
default point type in the PostgreSQL adapter. The old behavior will
continue to be available for the immediate future as `:legacy_point`.

The current behavior of returning an `Array` causes several problems,
the most significant of which is that we cannot differentiate between an
array of points, and a point itself in the case of a column with the
`point[]` type.

The attributes API gives us a reasonable way to have a proper
deprecation cycle for this change, so let's take advantage of it. If we
like this change, we can also add proper support for the other geometric
types (line, lseg, box, path, polygon, and circle), all of which are
just aliases for string today.

Fixes #20441

Related with #17370.

Example:

    create_table :foos do |t|
      t.string :string_en, collation: 'en_US.UTF-8'
      t.text   :text_ja,   collation: 'ja_JP.UTF-8'
    end

`use_transactional_fixtures` was deprecated in favor of
`use_transactional_tests` in Rails 5.0. This removes one warning while
running test suite.

The type map was introduced in aafee233, but wasn't properly filled.

This mainly adjusts many locations, that expected strings instead of
integers or boolean.

add_pg_decoders is moved after setup of the StatementPool, because
execute_and_clear could potentially make use of it.

This is implemented in Type::Float, but not tested, so far.

Fixes #19389.

I’m renaming all instances of `use_transcational_fixtures` to
`use_transactional_tests` and “transactional fixtures” to
“transactional tests”.

I’m deprecating `use_transactional_fixtures=`. So anyone who is
explicitly setting this will get a warning telling them to use
`use_transactional_tests=` instead.

I’m maintaining backwards compatibility—both forms will work.
`use_transactional_tests` will check to see if
`use_transactional_fixtures` is set and use that, otherwise it will use
itself. But because `use_transactional_tests` is a class attribute
(created with `class_attribute`) this requires a little bit of hoop
jumping. The writer method that `class_attribute` generates defines a
new reader method that return the value being set. Which means we can’t
set the default of `true` using `use_transactional_tests=` as was done
previously because that won’t take into account anyone using
`use_transactional_fixtures`. Instead I defined the reader method
manually and it checks `use_transactional_fixtures`. If it was set then
it should be used, otherwise it should return the default, which is
`true`. If someone uses `use_transactional_tests=` then it will
overwrite the backwards-compatible method with whatever they set.

This change was prompted by 598b8418.

The table is being modified in tests, without reloading the column
information on the appropriate class. This is leading to incorrect
column information in many cases.

The failures fixed by this commit can be replicated with:

    ARCONN=postgresql ruby -Itest test/cases/adapters/postgresql/hstore_test.rb --seed 21574

The default value of `"pg_arrays"."tags"` is being changed to `[]` in
one test, but the column information on the model isn't reset after it's
changed back. As such, we think the default value is `[]` when in the
database it's actually `nil`. That means any test which was assigning
`[]` to a new record would have that key skipped with partial writes, as
it hasn't changed from the default. However since the *actual* default
value is `nil`, we get back values that the test doesn't expect, and it
fails.

Example:

    create_table :foos do |t|
      t.string :string_utf8_bin, charset: 'utf8', collation: 'utf8_bin'
      t.text   :text_ascii,      charset: 'ascii'
    end

`PostgresqlLargeKeysTest` is duplicated `PrimaryKeyBigSerialTest` in
`primary_keys_test.rb`.

MySQL unicode support is not only `utf8mb4`.
Then, The index length problem is not only `utf8mb4`.

http://dev.mysql.com/doc/refman/5.6/en/charset-unicode.html

    SELECT * FROM information_schema.character_sets WHERE maxlen > 3;
    +--------------------+----------------------+------------------+--------+
    | CHARACTER_SET_NAME | DEFAULT_COLLATE_NAME | DESCRIPTION      | MAXLEN |
    +--------------------+----------------------+------------------+--------+
    | utf8mb4            | utf8mb4_general_ci   | UTF-8 Unicode    |      4 |
    | utf16              | utf16_general_ci     | UTF-16 Unicode   |      4 |
    | utf16le            | utf16le_general_ci   | UTF-16LE Unicode |      4 |
    | utf32              | utf32_general_ci     | UTF-32 Unicode   |      4 |
    +--------------------+----------------------+------------------+--------+

[Toby Ovod-Everett & Andrey Nering & Yves Senn]

Closes #17726.
Closes #10939.

This patch makes three distinct modifications:

1. no longer fall back to disabling user triggers if system triggers can't be disabled
2. warn the user when referential integrity can't be disabled
3. restore aborted transactions when referential integrity can't be disabled

The motivation behind these changes is to make the behavior of Rails
transparent and less error-prone. To require superuser privileges is not optimal
but it's what Rails currently needs. Users who absolutely rely on disabling user triggers
can patch `disable_referential_integrity`.

We should investigate `SET CONSTRAINTS` as a possible solution which does not require
superuser privileges.

/cc @matthewd

Lowercase raw SQL has been replaced by 07b659ca already. This commit
replaces everything else of raw SQL.

/cc @yahonda

This makes it easier for third party adapters to run our tests,
even if that database does not support IF EXISTS.

The datetime precision tests for any adapters is duplicated.

Also removed some cruft in the `setup` and `teardown` methods.

`precision: 0` was not dumped by f1a0fa9e.
However, `precision: 0` is valid value for PostgreSQL timestamps.

The various databases don't actually need significantly different
handling for this behavior, and they can achieve it without knowing
about the type of the object.

The old implementation was returning a string, which will cause problems
such as breaking TZ aware attributes, and making it impossible for the
adapters to supply their logic for time objects.

If timestamp column have the precision, it need to format according to
the precision of timestamp column.