This patch has been applied to DBDpg and will appear in the next
official release. Thanks.
---------------------------------------------------------------------------
Pete Leonard wrote:
>
> I'm installing DBD::Pg 1.13 on a new box, and it's not passing 3 tests in
> 04execute.t, which tests bind behavior. Tests # 5 & 6 are simply
> broken tests (expected results are backwards, fixes are in the patch file
> at the bottom of this email).
>
> #7 brings up bigger questions-
>
> The test, as it reads:
>
> eval {
> local $dbh->{PrintError} = 0;
> $sth = $dbh->prepare(q{
> SELECT id
> , name
> FROM test
> WHERE id = ?
> AND name = ?
> });
> $sth->execute();
> };
> if ($@) {
> print "ok $n\n"; $n++;
> } else {
> print "not ok $n\n"; $n++;
> }
>
> This should throw a big wonking error, as no values have been attached to
> the placeholders. It doesn't. Re-running this test with DBI->trace(2)
> shows that instead of crapping out, it re-assigns values of NULL, and runs
> the query:
>
> -> prepare for DBD::Pg::db (DBI::db=HASH(0x820b598)~0x820b4d8 '
> SELECT id
> , name
> FROM test
> WHERE id = ?
> AND name = ?
> ')
> dbd_st_prepare: statement = >
> SELECT id
> , name
> FROM test
> WHERE id = ?
> AND name = ?
> <
> dbd_st_preparse: statement = >
> SELECT id
> , name
> FROM test
> WHERE id = ?
> AND name = ?
> <
> dbd_preparse scanned 2 distinct placeholders
> <- prepare= DBI::st=HASH(0x8212a9c) at 04execute.t line 94
> -> DESTROY for DBD::Pg::st (DBI::st=HASH(0x8212acc)~INNER)
> dbd_st_finish
> dbd_st_destroy
> <- DESTROY= undef at 04execute.t line 101
> -> execute for DBD::Pg::st (DBI::st=HASH(0x8212a9c)~0x820b664)
> dbd_st_execute
> dbd_st_execute: statement = >
> SELECT id
> , name
> FROM test
> WHERE id = NULL
> AND name = NULL
> <
> <- execute= '0E0' at 04execute.t line 101
> -> STORE for DBD::Pg::db (DBI::db=HASH(0x820b4d8)~INNER 'PrintError'
> 1)
> dbd_db_STORE
> <- STORE= 1 at 04execute.t line 91
>
>
> So here's the question - is this standard operating procedure for DBI/DBD,
> to rewrite missing bind vars as undef, and therefore NULL in the SQL? If
> so, the test is simply broken, and can be fixed by simply reversing
> the result handling. If not, what is expected behavior? Should undef be
> getting rewritten as NULL? should execute(undef,undef) be legal, but crap
> out on execute()?
>
>
> Patch for tests 5 & 6 (current 1.13 tests 5&6 want failure as ok, when the
> behavior is fine & shouldn't fail):
>
> --- t/04execute.t~ 2002-11-13 22:05:06.000000000 +0000
> +++ t/04execute.t 2002-11-13 22:06:24.000000000 +0000
> @@ -62,9 +62,9 @@
> $sth->execute();
> };
> if ($@) {
> - print "ok $n\n"; $n++;
> - } else {
> print "not ok $n\n"; $n++;
> + } else {
> + print "ok $n\n"; $n++;
> }
>
> eval {
> @@ -81,9 +81,9 @@
> $sth->execute();
> };
> if ($@) {
> - print "ok $n\n"; $n++;
> - } else {
> print "not ok $n\n"; $n++;
> + } else {
> + print "ok $n\n"; $n++;
> }
>
> eval {
>
>
>
>
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073
