MySQL does not support partial index. And, the create index algorithm in
create table can not be specified.

Some databases like MySQL allow defining collation charset for specific
columns.

`change_column_null` is doc'ed only in
ActiveRecord::ConnectionAdapters::SchemaStatements, so it would make
sense to :nodoc: it elsewhere.

It behaves in the same way that the abstract adapter.

[ci skip]

to support MySQL 5.7.6 `optimizer_switch='derived_merge=on'`

Example:

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

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 |
    +--------------------+----------------------+------------------+--------+

Only `primary_key` should be extracted by d47357e2 in #19030, but
`new_coclumn_definition` was also extracted because #17631 is merged
previously, then #19030 is auto merged without conflicts.

This commit is for move back `new_column_definition` into
`TableDefinition`.

Example:

    create_table :foos, id: :primary_key, limit: 8 do |t|
    end

    # or

    create_table :foos, id: false do |t|
      t.column :id, limit: 8
    end

It is also necessary to format a time column like a datetime column.

This reverts commit 1502caef.

The test suite for the mysql adapter broke when this commit was used
with MySQL 5.6.

Conflicts:
	activerecord/CHANGELOG.md

We do this in the adapter classes specifically, so the types aren't
registered if we don't use that adapter. Constants under the PostgreSQL
namespace for example are never loaded if we're using mysql.

`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.

The same is not true of `define_attribute`, which is meant to be the low
level no-magic API that sits underneath. The differences between the two
APIs are:

- `attribute`
  - Lazy (the attribute will be defined after the schema has loaded)
  - Allows either a type object or a symbol
- `define_attribute`
  - Runs immediately (might get trampled by schema loading)
  - Requires a type object

This was the last blocker in terms of public interface requirements
originally discussed for this feature back in May. All the
implementation blockers have been cleared, so this feature is probably
ready for release (pending one more look-over by me).

The type from the column is never used, except when being passed to the
attributes API. While leaving the type on the column wasn't necessarily
a bad thing, I worry that it's existence there implies that it is
something which should be used.

During the design and implementation process of the attributes API,
there have been plenty of cases where getting the "right" type object
was hard, but I had easy access to the column objects. For any
contributor who isn't intimately familiar with the intents behind the
type casting system, grabbing the type from the column might easily seem
like the "correct" thing to do.

As such, the goal of this change is to express that the column is not
something that should be used for type casting. The only places that are
"valid" (at the time of this commit) uses of acquiring a type object
from the column are fixtures (as the YAML file is going to mirror the
database more closely than the AR object), and looking up the type
during schema detection to pass to the attributes API

Many of the failing tests were removed, as they've been made obsolete
over the last year. All of the PG column tests were testing nothing
beyond polymorphism. The Mysql2 tests were duplicating the mysql tests,
since they now share a column class.

The implementation is a little hairy, and slightly verbose, but it felt
preferable to going back to 20 constructor options for the columns. If
you are git blaming to figure out wtf I was thinking with them, and have
a better idea, go for it. Just don't use a type object for this.

If set to `if_exists: true`, it generates a statement like:

    DROP TABLE IF EXISTS posts

This syntax is supported in the popular SQL servers, that is (at least)
SQLite, PostgreSQL, MySQL, Oracle and MS SQL Sever.

Closes #16366.

`visit_ChangeColumnDefinition` is the same "CHANGE column_name " + `visit_ColumnDefinition(o)`.

In most cases, `create_table_definition` called by table_name (the first
argument) only.

Incompatible to rounding behavior between MySQL 5.6 and earlier.

In 5.5, when you insert `2014-08-17 12:30:00.999999` the fractional part
is ignored. In 5.6, it's rounded to `2014-08-17 12:30:01`:

http://bugs.mysql.com/bug.php?id=68760

If it is not a default primary key, correctly dump the type and options.

Example:

    create_table :foos, id: :bigint do |t|
    end