`supports_primary_key?` was added to determine if `primary_key` is
implemented in the adapter in f0602214. But we already use `primary_key`
without `supports_primary_key?` (207f266c, 5f3cf424) and using
`supports_primary_key?` has been removed in #1318. This means that
`supports_primary_key?` is no longer used in the internal and Active
Record doesn't work without `primary_key` is implemented (all adapters
must implement `primary_key`).

Closes #27977

Currently schema dumper lost the unsigned option when primary key is
defined as bigint with unsigned. This commit fixes the issue.

Closes #27960

`test_composite_primary_key_out_of_order` should use `barcodes_reverse`
table.

primary_keys(table) needs to query various metadata tables in Postgres to
determine the primary key for the table. Previously, it did so using a
complex common table expression against pg_constraint and pg_attribute.

This patch simplifies the query by joining pg_index against pg_attribute
instead of going through pg_constraint. This avoids an expensive unnest,
window function query, and common table expression.

EXPLAINing these queries in Postgres against a database with a single
table with a composite primary key shows a 66% reduction in the plan and
execute latencies. This is significant during application startup time,
especially against very large schemas, where these queries would be even
slower and more numerous.

Closes #27949

Some custom primary key tests (added at #17631, #17696, #18220, #18228)
were lost at #26266. Restore the tests to improve test coverage.

The PR #27384 changed integer-like primary key to be autoincrement
unless an explicit default. This means that integer-like primary key is
restored as autoincrement unless dumping the default nil explicitly.
We should dump integer-like primary key with default nil correctly.

`supports_primary_key?` method is defined in `AbstractAdapter` so does
not raise any errors.

Follow up to #27272.

Using `:auto_increment` option for abstracting the DB-specific auto
incremental types. It is worth to ease to implement the compatibility
layer.

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

Actually schema dumper/creation supports composite primary key (#21614).
Therefore it should not show the warning about composite primary key in
connection adapter.

This change moves the warning to `AttributeMethods::PrimaryKey` and
suppress the warning for habtm join table.

Fixes #25388.

Because causing an extra query by `sql_for_insert` for guessing a
primary key.
https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/connection_adapters/postgresql/database_statements.rb#L121-L125

Fixes #25300.

Follow up to #18228.

In MySQL and PostgreSQL, primary key is to be `NOT NULL` implicitly.
But in SQLite it must be specified `NOT NULL` explicitly.

If `AR.primary_key` is called for a table who has composite primary key,
the method returns `nil`. This behavior sometimes generates invalid SQL.
The first time developers notice to invalid SQL is when they execute
SQL. This commit enables developers to know they are doing something
dangerous as soon as possible.

Reported on #21509, how views is treated by `#tables` are differ
by each adapters. To fix this different behavior, after Rails 5.0
is released, deprecate `#tables`.

And `#table_exists?` would check both tables and views.
To make their behavior consistent with `#tables`, after Rails 5.0
is released, deprecate `#table_exists?`.

Such as #10404, #18206.

Example:

    create_table :barcodes, primary_key: ["region", "code"] do |t|
      t.string :region
      t.integer :code
    end

Example:

    create_table :foos do |t|
      t.integer :unsigned_integer, unsigned: true
      t.bigint  :unsigned_bigint,  unsigned: true
      t.float   :unsigned_float,   unsigned: true
      t.decimal :unsigned_decimal, unsigned: true, precision: 10, scale: 2
    end

 - Followup of https://github.com/rails/rails/pull/20190/.

    `widgets` table is being created in `primary_keys_test.rb` for PostgreSQLAdapter, MysqlAdapter, Mysql2Adapter
    and it makes test to fail earlier.

    Before:
      `bundle exec rake mysql2:test`

    ```
    Finished in 127.287669s, 35.5258 runs/s, 97.8885 assertions/s.

      1) Error:
    PersistenceTest::SaveTest#test_save_touch_false:
    ActiveModel::UnknownAttributeError: unknown attribute 'name' for #<Class:0x0000000a7d6ef0>.
        /home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:36:in `rescue in _assign_attribute'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:34:in `_assign_attribute'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:40:in `block in _assign_attributes'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:39:in `each'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:39:in `_assign_attributes'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:26:in `_assign_attributes'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:33:in `assign_attributes'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/core.rb:293:in `initialize'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/inheritance.rb:61:in `new'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/inheritance.rb:61:in `new'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/persistence.rb:50:in `create!'
        /home/kd/projects/kd-rails/activerecord/test/cases/persistence_test.rb:913:in `test_save_touch_false'

    4522 runs, 12460 assertions, 0 failures, 1 errors, 4 skips
    ```

    After:
      `bundle exec rake mysql2:test`

    ```
       Finished in 135.785086s, 33.3026 runs/s, 91.7774 assertions/s.

       4522 runs, 12462 assertions, 0 failures, 0 errors, 4 skips
    ```

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.

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

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

since 'drop table if exists' statement does not always work with some databases such as Oracle.
also Oracle drop table statement will not drop sequence objects.

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

Example:

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