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

When running the following migration:

    change_table(:table_name) { |t| t/timestamps }

The following error was produced:

    wrong number of arguments (2 for 1) .... /connection_adapters/abstract/schema_statements.rb:851:in `remove_timestamps'

This is due to `arguments` containing an empty hash as its second
argument.

Some comments that are meant to separate blocks of code in a file show up
on http://api.rubyonrails.org as though they were part of the documentation.

This commit hides those comments from the documentation.

Stems from the discussion with @zzak at https://github.com/voloko/sdoc/issues/79#issuecomment-64158738

[ci skip]

Why are people assigning booleans to string columns? >_>

We unintentionally changed the behavior on Sqlite3 and PostgreSQL.
Boolean values should cast to the database's representation of true and
false. This is 't' and 'f' by default, and "1" and "0" on Mysql. The
implementation to make the connection adapter specific behavior is hacky
at best, and should be re-visted once we decide how we actually want to
separate the concerns related to things that should change based on the
database adapter.

That said, this isn't something I'd expect to change based on my
database adapter. We're storing a string, so the way the database
represents a boolean should be irrelevant. It also seems strange for us
to give booleans special behavior at all in string columns. Why is
`to_s` not sufficient? It's inconsistent and confusing. Perhaps we
should consider deprecating in the future.

Fixes #17571

The MySQLAdapter type map used the lowest priority for enum types.
This was the result of a recent refactoring and lead to some broken lookups
for enums with values that match other types. Like `8bit`.

This patch restores the priority to what we had before the refactoring.

/cc @sgrif

it doesn't work on SQLite3 since it doesn't support truncate, but that's
OK.  If you call truncate on the connection, you're now bound to that
database (same as if you use hstore or any other db specific feature).