Expand the query used in #table_exists? to include materialized views in the
kinds of relations it searches.

Also do not use transactional fixtures. We drop the type and the
table after every run, so there is nothing for the transaction to clean up.

Creating and dropping similar tables within the same connection causes postgresql to look up old values in the cache of tables which have already been dropped.

This patch registers custom domains in our OID-type_map.
They will behave exactly as the type specified by `pg_type.typbasetype`.

/cc @matthewd

I ran the whole test suite and compared the old to the new types.
Following is the list of types that did change with this patch:

```
DIFFERENT TYPE FOR mood: NEW: enum, BEFORE:
DIFFERENT TYPE FOR floatrange: NEW: floatrange, BEFORE: float
```

The `floatrange` is a custom type. The old type `float` was simply a coincidence
form the name `floatrange` and our type-guessing.

fixes #10613

See https://github.com/rails/rails/blob/master/activesupport/lib/active_support/notifications.rb#L131

This will keep the test suite passing with older PG installations.

This setups the helper method which other tests can benefit from.

The pk_an_sequence_for query previously joined against pg_class's oid
for rows in pg_depend, but pg_depend's objid may point to other system
tables, such as pg_attrdef.  If a row in one of those other tables
coincidentally has the same oid as an (unrelated) sequence, that
sequence name may be returned instead of the real one.

This ensures that only the pg_depend entries pointing to pg_class are
considered.

It wasn't doing anything beyond clearing the statement cache.

Follow-Up to https://github.com/rails/rails/pull/14348

Ensure that SQLCounter.clear_log is called after each test.

This is a step to prevent side effects when running tests. This will allow us to run them in random order.

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

Related - https://github.com/rails/rails/commit/5c55aafd38f45ac019573f98438ffdbdc8c580f9

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

This test currently outputs the following warning:

```
unknown OID: current_mood(3567879) (SELECT  "postgresql_enums".* FROM "postgresql_enums"   ORDER BY "postgresql_enums"."id" ASC LIMIT 1)
unknown OID: current_mood(3567879) (SELECT  "postgresql_enums".* FROM "postgresql_enums"  WHERE "postgresql_enums"."id" = $1 LIMIT 1)
```

We have an open PR to deal with this issue. It will dynamically
register the OID for enum columns. This test case is merely to exhibit
the current behavior of PostgreSQL enum columns.

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.

Thanks Godfrey Chan for reporting this!

Fixes: CVE-2014-0080

We didn't have enough encoding for the wire protocol to store an array
of hstore types. So, further encode any hstore that is an array member.
Whilst we're here, ensure it's an HashWithIndifferentAccess being
returned, to be consistent with other serialized forms, and add testing
for arrays of hstore.

So now the following migration:

  enable_extension "hstore"
  create_table :servers do |t|
    t.string  :name
    t.hstore  :interfaces, array: true
  end

produces a model that can used like this, to store an array of hashes:

  server = Server.create(name: "server01", interfaces: [
    { name: "bge0", ipv4: "192.0.2.2", state: "up" },
    { name: "de0", state: "disabled", by: "misha" },
    { name: "fe0", state: "up" },
  ])

More at http://inopinatus.org/2013/07/12/using-arrays-of-hstore-with-rails-4/

remove created state after test execution, not before the next test.
This prevents the leak of the `ex` table outside of a single test.

This should make it harder to accidentally break this test.

If the test is run in a timezone that is behind UTC it fails because
the time generated is ahead of 0000-01-01 00:00:00. Just increase the
time subtracted so that timezone has no effect.

  - 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