Refactor SQL::Expression attribute handling

This makes it more like the rest of Sequel, copying data into
the subclass in inherited instead of calling superclass at
runtime.
Add Sequel.char_length for an emulated function returning the character length

I'm planning on using this feature for some upcoming work, plus
I've always wanted to add something like this, but never could
think of a good place to do so.  Now that the SQL::Builders
module has been added, this seems like a good place.

The basic reasoning here is that Sequel does a good job making
database access database agnostic.  However, one area where
Sequel didn't do a good job before is with database functions.
While there are quite a few standard SQL functions (including
char_length), not all databases support them.  This new emulated
functions feature is a way to get an abstract function object
that the adapters will literalize into the appopriate function
call for that database.

If this new support were around when the extract emulation was added,
I would have definitely used this for extract.  However, I don't think
changing the extract code to use an emulated function is worth it.
Support an emulated trim function

This adds support for an emualted trim function.  The only database
that appears to not support it by default is Microsoft SQL Server,
so there it is emulated with ltrim and rtrim.
Raise an error if attempting to use a Regexp pattern match on a database that doesn't support it

Before, Sequel used the PostgreSQL regexp format on most databases,
which would probably result in the database raising an error.  This
makes Sequel raise an exception while producing the SQL.

This adds Dataset#supports_regexp? for checking for support.  With
this change, integration tests can be added to check for correct
behavior, since they can be conditional on the supports_regexp?
method.
Don't require a :type when dropping constraints on SQLite

Previously, if a type was not specified, an error was raised.
However, other than primary key and foreign key constraints,
there are unique and check constraints, which can both be
handled similarly.

This allows you to drop check constraints on SQLite, though
it drops all check constraints instead of just the one listed.
Fix some RDoc in schema_generator.rb
Add new apply_alter_table_generator for easier overriding

This change allows the method to modify the generator's
operations before using those operations to modify the
table.
Add constraint_validations extension and plugin

The extension allows you to create database constraints that mirror
model validations when creating and altering tables.  It adds
validation metadata to a separate table.  The plugin reads the
metadata from that table, and uses it to automatically validate your
models before saving.

The advantage to doing so is that your validations are only specified
in one place, but are enforced both at the model level and at the
database level.  This is better for data integrity, since it
enforces the validation for all rows in the database, so changes
made by external programs or via the dataset layer are still
covered.
Handle sets of alter_table operations on mysql and mssql where later operations depend on earlier ones

Some alter_table operations on mysql and mssql require parsing the
schema to get current metadata.  If you have multiple alter_table
operations that modify the same column, this can cause problems,
since all of the alter table queries are generated before being
run on the database.  For example:

  DB.alter_table(:foo)
    rename_column(:bar, :baz)
    set_column_type(:baz, Integer)
  end

On both MySQL and MSSQL, this would fail, since when generating
the set_column_type SQL, it would look for the baz column in the
schema, but that won't exist since the rename_column SQL has
not yet been run.

To fix this, preprocess the array of operations and split it
into multiple arrays.  Between the execution of SQL in each array,
remove the cached schema, so that the next set of operations will
have accurate schema information.

The implementation of the methods is the same for both of these,
except for one line (MSSQL doesn't need to parse the schema to
set a new default).  I thought about abstracting this into a
separate method, but I feel the implementations may diverge
further in the future, so I'm not convinced it is worth it.
Combine multiple alter_table operations into a single query where possible on MySQL and PostgreSQL

ActiveRecord has been doing this since 3.1, though just for MySQL
and not by default (it requires a separate :bulk=>true option).

This change may be risky, as it can change the SQL used for old
migrations, but hopefully it shouldn't cause problems.  This
preprocesses the alter table operations array and if it detects
operations that can't be combined (e.g. add/drop index operations
or rename column operations on PostgreSQL), it uses separate
queries for those.

If this causes problems that can't be easily fixed, this will be
turned off by default and only enabled via an option.  A simple
way to skip this combining manually is to use separate alter_table
blocks for each operation.

To implement this, alter_table_op_sql is split off
alter_table_sql, and returns just the fragment used.  Multiple
fragments can be separated by commas in a single ALTER TABLE query.

If the adapter does not support combining alter table operations,
then no changes are necessary.  However, if it does enable support
for combining operations, it must implement alter_table_op_sql to
handle overrides for the operations, or mark such operations as
not combinable.

It's possible to support something similar on Microsoft SQL
Server, but the syntax is different, and appears to be much
more limited, only adding multiple columns/constraints at once or
dropping multiple columns/constraints at once, but not mixing
adds and drops.  I don't have current plans to adding a similar
feature to Microsoft SQL Server.

Also, this changes the code to assume that alter_table_sql_list
returns an already flattened array.  Any custom adapters that
override alter_table_sql_list should make sure that they return a
flattened array.
Skip combining alter table spec on jdbc/db2 and native db2

These adapters probably don't like the set_column_type calls,
so add guards just like for the set_column_type specs.
Add Database#copy_into when using postgres adapter with pg driver, for very fast inserts into tables

This uses PostgreSQL's COPY table FROM STDIN support to get really
fast inserts when using data preformatted in CSV or PostgreSQL
text format.  Support for COPY table TO STDOUT was added last
year, but previous Sequel did not support that and you had to
drop down to the connection level, which doesn't offer an
API that is as nice.
Fix serial sequence query in Database#primary_key_sequence on PostgreSQL (Fixes #538)

The serial sequence query was previously broken, since it checked
if the sequence name was equal to the table name, which is wrong.
So in all cases previously, it fell back to using the custom
sequence query.

Modify the query to check that the table name matches.  While here,
always quote the table name if the serial sequence query matches,
since unlike the custom sequence query, the serial sequence query
doesn't deal with literal strings.
Don't include date part in Sequel::SQLTime eval_inspect output

This should be a no-op, but results in more readable output.
Make NegativeBooleanConstant inherit from Constant

Before, it inherited from BooleanConstant, which is wrong as it
lead to Sequel::NULL == Sequel::NOTNULL.
Nicer eval_inspect output for Sequel::CURRENT_DATE and similar constants
Make schema_dumper handle CURRENT_DATE/CURRENT_TIMESTAMP

Since we started using CURRENT_DATE/CURRENT_TIMESTAMP for
:ruby_default, the schema_dumper has not been able to dump
such values correctly.  To fix this, instead of only
using the eval_inspect extension for a very specific case,
include it generally, and just use eval_inspect to get the
default value.

In addition to the CURRENT_DATE/CURRENT_TIMESTAMP fix, this
also preserves any fractional seconds in time/datetime default
values when dumping.
Handle Sequel::CURRENT_{DATE,TIMESTAMP} values in the defaults_setter plugin

Since Sequel started parsing current date/timestamp values from the
database, the defaults setter has just used the values directly,
which is probably not desired as they represent database concepts
instead of concrete values.  Instead, convert the values into
the current Date or Time/DateTime.

While here, fix the defaults setter to actually set false default
values.
Fix potential thread-safety issues on PostgreSQL on non-GVL rubies

Similar to previous changes in the general library, this makes
the shared postgres adapter require synchronization for the
@primary_keys and @primary_key_sequences hashes for
Database instances, since multiple threads could potentially
attempt to update them concurrently.
Fix assorted documentation typos.