- 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 5ac2341f `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

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.

This reverts commit 3043d45e, reversing
changes made to ca0275d3.

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 .

Introduced in 09ac1776.

without this, it's not possible to use UUID primary keys without uuid-ossp installed and activated

Adds support for algorithm option in MySQL indexes
Moves USING and algorithm options upstream

The syntax is still specific to the Adapter, so the actual executed string happens
in the corresponding adapter

Created a layer of abstraction for the valid type checking in schema dumper. Now, connection handles the check for valid types so that each database can handle the changes individually.