I am fixing some glitches involved in running the t/*.t tests for
DBD::CSV with the new SQL::Statement and have reduced things to two
differences between the old and new Statement and am not sure how to
proceed.
1. The new SQL::Statement will allow manipulation of blobs, but only
with placeholders:
This only works in the XS version of SQL::Statement:
$dbh->do("INSERT INTO foo VALUES( $blob )");
But this works in both versions:
$dbh->do("INSERT INTO foo VALUES( ? )",undef,$blob);
Personally, I am in favor of keeping the new behaviour and requiring
that blobs be handled with placeholders. Is that a good decision? How
do other drivers handle this?
2. The new SQL::Statement will not allow empty strings to be treated as
NULLs, thus:
These worked in XS bersion but don't in the new version:
$dbh->do("INSERT INTO foo VALUES( '' )");
$dbh->prepare("SELECT * FROM foo WHERE frump = '' ");
But these work in both versions:
$dbh->do("INSERT INTO foo VALUES( NULL )");
$dbh->prepare("SELECT * FROM foo WHERE frump IS NULL );
Again, I am in favor of keeping the new behaviour becuase it seems more
like SQL than like Perl. Do other drivers allow treating an empty
string as a NULL?
With both of these questions, I'm interested both in a theoretical
answer and in the practical matter of how the decisions might impact
existing DBD::CSV scripts using the old behaviour.
Jochen, if I go with the new behaviour, would you be willing to accept
patches for blobs.t, chopblanks.t and ak-dbd.t that would either use the
new syntax or would throw warnings rather than exceptions so that
DBD::CSV will install without failing tests when the users have the new
Statement installed?
--
Jeff
