1.5 MySQL → Scheme Type Mapping

MySQL types are mapped to scheme types as follows:

MySQL Type		Scheme Type
NULL		sql-null?
BIT		exact-integer?
*INT		exact-integer?
FLOAT		real?
DOUBLE		real?
DECIMAL/NUMERIC		real?
NUMERIC		real?
DATETIME		srfi-19:date?
TIMESTAMP		srfi-19:date?
DATE		srfi-19:date?
TIME		srfi-19:time?
YEAR		exact-integer?
CHAR		string?
VARCHAR		string?
*TEXT		string?
BINARY		bytes?
VARBINARY		bytes?
*BLOB		bytes?

1.5.1 SQL NULL

The SQL NULL value is represented by the unique value sql-null.

1.5.2 Precision of Real Numbers in Prepared Statements

If you provide a real number as a parameter value to a prepared statement, the MySQL Client Library will send it to the server as a decimal string. To provide sufficient precision, the library will consult the decimals field of the parameter packet it received from the server (see MySQL Internals: Client/Server Protocol). If decimals is positive, it will encode the value as:

      (real->decimal-string real-value (add1 decimals))

Otherwise, it will default to:

      (number->string (exact->inexact real-value))

1.5.3 Dates

The SRFI 19 date struct type contains both date and time of day information, as well as timezone data. When an SQL DATE is mapped to an SRFI 19 date, the time of day data is zeroed out (and therefore corresponds to the very start of the day). When an SRFI 19 date is mapped back to an SQL DATE, the time of day data is simply ignored.

When the MySQL Client Library creates an SRFI 19 date value, its timezone offset is set to the offset of the local machine’s current locale. No automatic timezone adjustment is performed between client and server.

1.5.4 Times

SQL TIME values are mapped to SRFI 19 time structs, using the 'time-duration type. When mapped back to an SQL TIME, the SRFI-19 time is rounded to the nearest second.

1.5.5 Character Encoding

The MySQL Client Library communicates with the server using the UTF-8 encoding. (Note that this is completely independent of the encoding you have chosen for your database tables and/or columns. The MySQL server will re-encode your data into the appropriate character encoding for storage.)

Although MySQL allows users to change the character encoding of the client/server communication channel using the SET NAMES statement, you should not do this, as the client library has no way of detecting the change (short of parsing all SQL strings, looking for SET NAMES statements, which would be unreasonably expensive). Consequently, changing the encoding of the channel will likely result in data corruption.