[DB-SIG] Last round for DB API 1.1

[Greg Stein]

Andy Dustman wrote:
>...
> I can probably live with this. ODBC is somewhat of a special case, as it
> is a sort of intermediate interface to a lot of different databases. Note
> that according to the Solid docs for SQLTransact, a number of errors can
> occur during either commit or rollback, including "The driver or data
> source does not support the ROLLBACK operation". So a proper ODBC
> interface ought to produce an error resulting in a Python exception (I
> guess an OperationalError) when used with a database that does not support
> it. In fact, I'm willing to drop the AttributeError part and go with
> rollback always generating a OperationError on databases where rollback is
> not supported.

As I stated in another email: I would strongly suggest that an
AttributeError is highly preferable over an OperationError.

> > BTW: I've noticed that MySQL support BLOBs but does not handle
> > binary data in those BinaryLongOBjects... is that a bug in their ODBC
> > driver or by design ? [would render the Binary() constructor meaningless
> > I guess...]
> 
> I really don't know very much about their ODBC driver. The main "quirk"
> with MySQL seems to be that all queries are literal, i.e. when they are
> submitted with mysql_real_query(), the whole query with all values is one
> (possibly very large if you are doing multi-row inserts) byte-counted
> string. It is also necessary to escape all strings, whether binary or not,
> with mysql_escape_string, since it must escape ', \r, \n, and \0, and '
> may certainly appear in a non-binary string. It is also fortunate that

This is really bogus, unfortunately. I think there is also a limit on
the length of the SQL statement, meaning you can't insert those 537k
blobs :-(

Cheers,
-g

--
Greg Stein, http://www.lyra.org/