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 {



Reply via email to