Initialise the snaplet by providing it with a raw HDBC connection. A
resource pool is created with some default parameters that should be fine
for most common usecases. If a custom resource pool configuration is
desired, use the hdbcInit' initialiser instead. When the snaplet is
unloaded, the disconnect function is called to close any remaining
connections.

Similar to query, but instead of returning a list of Rows, it returns
an Integer indicating the numbers of affected rows. This is typically used
for INSERT, UPDATE and DELETE queries.
TODO: Revert to the implementation below once withTransaction' works as expected.

SqlValue is he main type for expressing Haskell values to SQL databases.

INTRODUCTION TO SQLVALUE

This type is used to marshall Haskell data to and from database APIs.
HDBC driver interfaces will do their best to use the most accurate and
efficient way to send a particular value to the database server.

Values read back from the server are constructed with the most appropriate SqlValue
constructor. fromSql or safeFromSql
can then be used to convert them into whatever type
is needed locally in Haskell.

Conversions are powerful; for instance, you can call fromSql on a SqlInt32
and get a String or a Double out of it. This class attempts to Do
The Right Thing whenever possible, and will raise an error when asked to
do something incorrect. In particular, when converting to any type
except a Maybe, SqlNull as the input will cause an error to be raised.

Conversions are implemented in terms of the Data.Convertible module, part of the
convertible package. You can refer to its documentation, and import that module,
if you wish to parse the Left result from safeFromSql yourself, or write your
own conversion instances.

There may sometimes be an error during conversion. For instance, if you have a
SqlString and are attempting to convert it to an Integer, but it doesn't parse as
an Integer, you will get an error. This will be indicated as an exception if using
fromSql, or a Left result if using safeFromSql.

HDBC database backends are expected to marshal date and time data back and
forth using the appropriate representation for the underlying database engine.
Databases such as PostgreSQL with builtin date and time types should see automatic
conversion between these Haskell types to database types. Other databases will be
presented with an integer or a string. Care should be taken to use the same type on
the Haskell side as you use on the database side. For instance, if your database
type lacks timezone information, you ought not to use ZonedTime, but
instead LocalTime or UTCTime. Database type systems are not always as rich
as Haskell. For instance, for data stored in a TIMESTAMP
WITHOUT TIME ZONE column, HDBC may not be able to tell if it is intended
as UTCTime or LocalTime data, and will happily convert it to both,
upon your request. It is
your responsibility to ensure that you treat timezone issues with due care.

This behavior also exists for other types. For instance, many databases do not
have a Rational type, so they will just use the show function and
store a Rational as a string.

The conversion between Haskell types and database types is complex,
and generic code in HDBC or its backends cannot possibly accomodate
every possible situation. In some cases, you may be best served by converting your
Haskell type to a String, and passing that to the database.

UNICODE AND BYTESTRINGS

Beginning with HDBC v2.0, interactions with a database are presumed to occur in UTF-8.

To accomplish this, whenever a ByteString must be converted to or from a String,
the ByteString is assumed to be in UTF-8 encoding, and will be decoded or encoded
as appropriate. Database drivers will generally present text or string data they have
received from the database as a SqlValue holding a ByteString, which fromSql will
automatically convert to a String, and thus automatically decode UTF-8, when
you need it. In the other direction, database drivers will generally convert
a SqlString to a ByteString in UTF-8 encoding before passing it to the
database engine.

If you are handling some sort of binary data that is not in UTF-8, you can of course
work with the ByteString directly, which will bypass any conversion.

Due to lack of support by database engines, lazy ByteStrings are not passed to database
drivers. When you use toSql on a lazy ByteString, it will be converted to a strict
ByteString for storage. Similarly, fromSql will convert a strict ByteString to
a lazy ByteString if you demand it.

EQUALITY OF SQLVALUE

Two SqlValues are considered to be equal if one of these hold. The
first comparison that can be made is controlling; if none of these
comparisons can be made, then they are not equal:

Both are NULL

Both represent the same type and the encapsulated values are considered equal
by applying (==) to them

The values of each, when converted to a string, are equal.

STRING VERSIONS OF TIMES

Default string representations are given as comments below where such are non-obvious.
These are used for fromSql when a String is desired. They are also defaults for
representing data to SQL backends, though individual backends may override them
when a different format is demanded by the underlying database. Date and time formats
use ISO8601 date format, with HH:MM:SS added for time, and -HHMM added for timezone
offsets.

DEPRECATED CONSTRUCTORS

SqlEpochTime and SqlTimeDiff are no longer created automatically by any
toSql or fromSql functions or database backends. They may still be manually
constructed, but are
expected to be removed in a future version. Although these two constructures will
be removed, support for marshalling to and from the old System.Time data will be
maintained as long as System.Time is, simply using the newer data types for conversion.

Like fetchRow, but instead of returning a list, return an association
list from column name to value.

The keys of the column names are lowercase versions of the data returned
by getColumnNames. Please heed the warnings there. Additionally,
results are undefined if multiple columns are returned with identical names.

Please note that the careless use of this function can lead to some unpleasant
behavior. In particular, if you have not consumed the entire list, then
attempt to finish or re-execute the statement, and then attempt to consume
more elements from the list, the result will almost certainly not be what
you want.

But then, similar caveats apply with hGetContents.

Bottom line: this is a very convenient abstraction; use it wisely.

Use fetchAllRows' if you need something that is strict, without
all these caveats.

Catches SqlErrors, and re-raises them as IO errors with fail.
Useful if you don't care to catch SQL errors, but want to see a sane
error message if one happens. One would often use this as a high-level
wrapper around SQL calls.