When table has a composite primary key, the `primary_key` method for
sqlite3 and postgresql was only returning the first field of the key.

Ensures that it will return nil instead, as AR dont support composite pks.

Closes #7247.

Conflicts:
	activerecord/CHANGELOG.md
	activerecord/test/models/owner.rb

Fixes #18237

This is no longer required now that we are injecting a type caster
object into the Arel table, with the exception of uniqueness
validations. Since it calls `ConnectionAdapter#type_cast`, the value has
already been cast for the database. We don't want Arel to attempt to
cast it further, so we need to continue wrapping it in a quoted node.
This can potentially go away when this validator is refactored to make
better use of `where` or the predicate builder.

We only support classes which provide a no-args constructor to use as a
default value. We can provide a more helpful error message if we catch
this when `serialize` is called, rather than letting it error when you
try to assign the attribute.

Fixes #18224

Example:

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

Part of the larger refactoring to remove type casting from Arel. We can
inform it that we already have the right type by wrapping the value in
an `Arel::Nodes::Quoted`. This commit can be reverted when we have
removed type casting from Arel in Rail 5.1

Part of the larger refactoring to remove type casting from Arel. We can
inform it that we already have the right type by wrapping the value in
an `Arel::Nodes::Quoted`. This commit can be reverted when we have
removed type casting from Arel in Rail 5.1

Part of the larger refactoring to remove type casting from Arel. We can
inform it that we already have the right type by wrapping the value in
an `Arel::Nodes::Quoted`. This commit can be reverted when we have
removed type casting from Arel in Rail 5.1

This will allow eager type casting to take place as needed. There
doesn't seem to be any particular reason that the `in` statement was
forced for single values, and the commit message where it was introduced
gives no context.

See
https://github.com/rails/rails/commit/d90b4e2615e8048fdeffc6dffe3246704adee01f

Part of a larger refactoring to remove type casting from Arel.

/cc @mrgilman

[Sean Griffin & Melanie Gilman]

As part of the larger refactoring to remove type casting from Arel, we
need to do the casting of values eagerly. The predicate builder is the
closest place that knows about the Active Record class, and can
therefore have the type information.

/cc @mrgilman

[Sean Griffin & Melanie Gilman]

This class cares far too much about the internals of other parts of
Active Record. This is an attempt to break out a meaningful object which
represents the needs of the predicate builder. I'm not fully satisfied
with the name, but the general concept is an object which represents a
table, the associations to/from that table, and the types associated
with it. Many of these exist at the `ActiveRecord::Base` class level,
not as properties of the table itself, hence the need for another
object. Currently it provides these by holding a reference to the class,
but that will likely change in the future. This allows the predicate
builder to remain wholy concerned with building predicates.

/cc @mrgilman

This will allow us to pass the predicate builder into the constructor of
these handlers. The procs had to be changed to objects, because the
`PredicateBuilder` needs to be marshalable. If we ever decide to make
`register_handler` part of the public API, we should come up with a
better solution which allows procs.

/cc @mrgilman

[Sean Griffin & Melanie Gilman]

Construction of relations can be a hotspot, we don't want to create one
of these in the constructor. This also allows us to do more expensive
things in the predicate builder's constructor, since it's created once
per AR::Base subclass

I think we should deprecate this behavior and just error if you tell us
to do a case insensitive comparison for types which are not case
sensitive. Partially reverts 35592307

Fixes #18195

We were ignoring the `default_value?` escape clause in the serialized
type, which caused the default value to always be treated as changed.

Fixes #18169

The code in `ConnectionPool#release` assumed that a single thread only
ever holds a single connection, and thus that releasing a connection
only requires the owning thread_id.

There is a trivial counterexample to this assumption: code that checks
out additional connections from the pool in the same thread. For
instance:

    connection_1 = ActiveRecord::Base.connection
    connection_2 = ActiveRecord::Base.connection_pool.checkout
    ActiveRecord::Base.connection_pool.checkin(connection_2)
    connection_3 = ActiveRecord::Base.connection

At this point, connection_1 has been removed from the
`@reserved_connections` hash, causing a NEW connection to be returned as
connection_3 and the loss of any tracking info on connection_1. As long
as the thread in this example lives, connection_1 will be inaccessible
and un-reapable. If this block of code runs more times than the size of
the connection pool in a single thread, every subsequent connection
attempt will timeout, as all of the available connections have been
leaked.

Reverts parts of 9e457a86 and
essentially all of 4367d2f0

This bug occurs when an attribute of an ActiveRecord model is an
ActiveRecord::Type::Integer type or a ActiveRecord::Type::Decimal type (or any
other type that includes the ActiveRecord::Type::Numeric module. When the value
of the attribute is negative and is set to the same negative value, it is marked
as changed.

Take the following example of a Person model with the integer attribute age:

    class Person < ActiveRecord::Base
      # age          :integer(4)
    end

The following will produce the error:

    person = Person.new(age: -1)
    person.age = -1
    person.changes
    => { "age" => [-1, -1] }
    person.age_changed?
    => true

The problematic line is here:

    module ActiveRecord
      module Type
        module Numeric
          ...

          def non_numeric_string?(value)
            # 'wibble'.to_i will give zero, we want to make sure
            # that we aren't marking int zero to string zero as
            # changed.
            value.to_s !~ /\A\d+\.?\d*\z/
          end
        end
      end
    end

The regex match doesn't accept numbers with a leading '-'.

If there is a method defined such as `find_and_do_stuff(id)`, which then
gets called on an association, we will perform statement caching and the
parent ID will not change on subsequent calls.

Fixes #18117

Calling `changed_attributes` will ultimately check if every mutable
attribute has changed in place. Since this gets called whenever an
attribute is assigned, it's extremely slow. Instead, we can avoid this
calculation until we actually need it.

Fixes #18029

PG will warn without it, but mysql2 errors out.

This has the same comments as 9af90ffa00ba35bdee888e3e1ab775ba0bdbe72c,
however it affects the `add_reference` method, and `t.references` in the
context of a `change_table` block.

There is a lot of duplication of code between creating and updating
tables. We should re-evaluate the structure of this code from a high
level so changes like this don't need to be made in two places. (Note to
self)

Rather than having to do:

    create_table :posts do |t|
      t.references :user
    end

    add_foreign_key :posts, :users

You can instead do:

    create_table :posts do |t|
      t.references :user, foreign_key: true
    end

Similar to the `index` option, you can also pass a hash. This will be
passed as the options to `add_foreign_key`. e.g.:

    create_table :posts do |t|
      t.references :user, foreign_key: { primary_key: :other_id }
    end

is equivalent to

    create_table :posts do |t|
      t.references :user
    end

    add_foreign_key :posts, :users, primary_key: :other_id

If the test is interrupted in a way that the teardown block fails to
run, the tests will fail to run until the table is removed manually
without this option.

PG doesn't register it's types using the `int(4)` format that others do.
As such, if we alias `int8` to the other integer types, the range
information is lost. This is fixed by simply registering it separately.

The other option (which I specifically chose to avoid) is to pass the
information of the original type that was being aliased as an argument.
I'd rather avoid that, since an alias should truly be treated the same.
If we need different behavior for a different type, we should explicitly
register it with that, and not have a conditional based on aliasing.

Fixes #18144

[Sean Griffin & ysbaddaden]

Fixes #18122

Apparently PG does not validate against RFC 4122. The intent of the original
patch is just to protect against PG errors (which potentially breaks txns, etc)
because of bad user input, so we shouldn't try any harder than PG itself.

Closes #17931

In the case of serialized columns, we would expect the unserialized
value as input, not the serialized value. The original issue which made
this distinction, #14163, introduced a bug. If you passed serialized
input to the method, it would double serialize when it was sent to the
database. You would see the wrong input upon reloading, or get an error
if you had a specific type on the serialized column.

To put it another way, `update_column` is a special case of
`update_all`, which would take `['a']` and not `['a'].to_yaml`, but you
would not pass data from `params` to it.

Fixes #18037