Apparently we've been using a buggy feature for the past 6 years:

  https://bugs.ruby-lang.org/issues/9593

Two bits of example code use sqlite as an adapter, which doesn't exist.
Using the code verbatim will raise a LoadError exception:

    ActiveRecord::Base.establish_connection(
      "adapter"  => "sqlite",
      "database" => "db.sqlite"
    )
    # => LoadError: Could not load 'active_record/connection_adapters/sqlite_adapter'...

Considering this is code a lot of people new to Rails might be running,
it's especially confusing.

Closes #14367 [ci skip]

You might want to branch it to include this only for 5.6, but
passing these values to < 5.6 doesn't cause issues either.

citext makes it possible to use AR Hash finders for case-insensitive matching as sql UPPER/LOWER functions are not needed.

PR #14052 Added a regression where it was only looking for methods in one
level up, So when the method was defined in a 2+ levels up the
inheritance chain, the method was not found as defined.

Thank you @bquorning

[ci-skip]
Closes rails/rails#14294

This method return `Gem::Version.new(Rails.version)`, suggesting a more
reliable way to perform version comparison.

Example:

    Rails.version #=> "4.1.2"
    Rails.gem_version #=> #<Gem::Version "4.1.2">

    Rails.version > "4.1.10" #=> false
    Rails.gem_version > Gem::Version.new("4.1.10") #=> true
    Gem::Requirement.new("~> 4.1.2") =~ Rails.gem_version #=> true

This was originally introduced as `.version` by @charliesome in #8501
but got reverted in #10002 since it was not backward compatible.

Also, updating template for `rake update_versions`.

origin: https://github.com/rails/rails/commit/f6aeb8b1a3687c8523e4a56309fe3736011b2935#commitcomment-5569649

This is a result of the discussion at https://github.com/rails/rails/pull/14263/files#r10291489

This behavior has almost no performance impact:

String not allowed  66.910000   0.030000  66.940000 ( 67.024976)
String allowed      69.360000   0.030000  69.390000 ( 69.503096)

Benchmarked with http://git.io/Y0YuRw.

When we build a query with an inline value that is a numeric (e.g.
because it's out of range for an int4) PostgreSQL doesn't use an index
on the column, since it's now comparing numerics and not int4s.

This leads to a _very_ slow query.

When we use bound parameters instead of inline values PostgreSQL
raises numeric_value_out_of_range since no automatic coercion happens.

- unused variable in PG Adapter.
- Ambiguous argument warning from range_test for use - to + Infinity range without brackets.

When replacing a has_many association with the same one, there is no
need to do a round-trip to the db to create/and drop a new transaction.

[fixes #14220]

This is a partial revert of 22b3481b.
The current implementation of `references_eager_loaded_tables?` needs to know
every table involved in the query. With the current API this is not possible
without SQL parsing.

While a2dab46c deprecated SQL parsing for `includes`.
It did not issue deprecation warnings when String joins are involved. This resulted
in a breaking change after the deprecated behavior was removed (22b3481b).

We will need to rethink the usage of `includes`, `preload` and `eager_load` but for now,
this brings back the old *working* behavior.

This fixes a bug where any enum attribute of a model
would be evaluated always as 0 when calling the
database on validations.

This fix converts the value of the enum attribute
to its integer value rather than the string before
building the relation as the bug occured when the
string finally gets converted to integer using
string.to_i which converts it to 0.

[Vilius Luneckas, Ahmed AbouElhamayed]

Active Record is specifically for databases. Refs #12101.

Make explanation of association class methods clearer by moving notes to beginning of each example section.

`before_add` callbacks are fired before the record is saved on
`has_and_belongs_to_many` assocations *and* on `has_many :through`
associations.  Before this change, `before_add` callbacks would be fired
before the record was saved on `has_and_belongs_to_many` associations, but
*not* on `has_many :through` associations.

Fixes #14144

conflicting private method defined on its ancestors.

The problem is that `method_defined_within?(name, klass, superklass)`
only works correclty when `klass` and `superklass` are both `Class`es.

If both `klass` and `superklass` are both `Class`es, they share the
same inheritance chain, so if a method is defined on `klass` but not
`superklass`, this method must be introduced at some point between
`klass` and `superklass`.

This does not work when `superklass` is a `Module`. A `Module`'s
inheritance chain contains just itself. So if a method is defined on
`klass` but not on `superklass`, the method could still be defined
somewhere upstream, e.g. in `Object`.

This fix works by avoiding calling `method_defined_within?` with a
module while still fufilling the requirement (checking that the
method is defined withing `superclass` but not is not a generated
attribute method).

4d8ee288 is likely an attempted partial fix for this problem. This
unrolls that fix and properly check the `superclass` as intended.

Fixes #11569.

The Ruby Range object does not support excluding beginnings.
We currently support excluding beginnings for some subtypes using
manually by incrementing them (now using the `#succ` method).
This is approach is flawed as it's not equal to an excluding beginning.

This commit deprecates the current support for excluding beginnings.
It also raises an `ArgumentError` for subtypes that do not implement the `succ`
method.

This is a temporary solution to get rid of the broken state. We might still
add complete support for excluding beginnings afterwards. (Probably with a
new `PGRange` object, which acts like a `Range` but has excluding beginnings.

This gets AR working with custom defined range types. It also
removes the need for subtype specific branches in `OID::Range`.

This expands the interface of all `OID` types with the `infinity` method.
It's responsible to provide a value for positive and negative infinity.

Distinguish ConnectionNotEstablished messages: no conn pool for the class, or no conn available from the pool

If using a `DATABASE_URL` and a `database.yml`. The connection information in `DATABASE_URL` should be merged into whatever environment we are in. As released in 4.1.0rc1 if someone has a database.yml but is missing a key like production:

```yml
development:
  host: localhost

```

Then the check for blank config will return false so the information from the `DATABASE_URL` will not be used when attempting to connect to the `production` database and the connection will incorrectly fail.

This commit fixes this problem and adds a test for the behavior.

In addition the ability to specify a connection url in a `database.yml` like this:

```
production: postgres://localhost/foo
```

Was introduced in 4.1.0rc1 though should not be used, instead using a url sub key

```
production:
  url: postgres://localhost/foo
```

This url sub key was also introduced in 4.1.0rc1 though the `production: postgres://localhost/foo` was not removed. As a result we should not test this behavior.

This reverts commit 5e3d466d.

This reverts commit f9e4c3c7.

[fixes #14116]