Most data is returned to the Perl script as strings. (Null values are
returned as undef.) This allows arbitrary
precision numeric data to be handled without loss of accuracy. Beware
that Perl may not preserve the same accuracy when the string is used
as a number.
Dates and times are returned as character strings in the native
format of the corresponding database engine. Time zone effects are
database/driver-dependent.
Perl supports binary data in Perl strings, and the DBI will pass
binary data to and from the driver without change. It is up to the
driver implementors to decide how they wish to handle such binary
data.
Most databases that understand multiple character sets have a default
global charset. Text stored in the database is, or should be, stored
in that charset; if not, then that's the fault of either the
database or the application that inserted the data. When text is
fetched, it should be automatically converted to the charset of the
client, presumably based on the locale. If a driver needs to set a
flag to get that behavior, then it should do so; it should not
require the application to do that.
Multiple SQL statements may not be combined in a single statement
handle ($sth), although some databases and drivers
do support this feature (notably Sybase and SQL Server).
Non-sequential record reads are not supported in this version of the
DBI. In other words, records can be fetched only in the order that
the database returned them, and once fetched they are forgotten.
Positioned updates and deletes are not directly supported by the DBI.
See the description of the CursorName attribute
for an alternative.
Individual driver implementors are free to provide any private
functions and/or handle attributes that they feel are useful. Private
driver functions can be invoked using the DBI
func() method. Private driver attributes are
accessed just like standard attributes.