-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160
> It's perfectly valid (from the DBI's point of view) for prepare() to
> return a prepared statement handle for an invalid statement.
>
> It's not the job of prepare() to validate the SQL. It's a bonus if it
> does, but the primary goal is "to prepare as much as possible" for
> future execution.
>
> There are *many* DBI drivers that can't/don't validate the SQL on
> prepare. DBD::Oracle, for example, can but doesn't by default.
> It defers the prepare until the first execute (or meta data is
> requested) in order to reduce the number of round-trips.
Just to set the record straight on this thread, DBD::Pg also defers
actual preparation until needed (e.g. the first execute) and thus
will accept all prepare statements, regardless of what is inside
of them. It does this not only to save trips, but because bind_param
may be called betwixt the prepare and the execute.
This works fine with DBD::Pg:
$sth = $dbh->prepare('foobar');
However, this will then fail:
$sth->execute();
Thus, as pointed out elsewhere, the original report was not correct:
the error comes when execute() is called, not when prepare() is.
> p.s. I'd be happy to see 'success with info' status returned if the
> prepare() has to unexpectly fallback to client-side (and perhaps a dbh
> counter incremeted). So users can tell when and how often it's happening
> if they want to.
For DBD::Pg, this is not possible as prepare always works. Even if it didn't,
I think the fallback idea is not a good one, as we'd be potentially creating
many errors to have to rollback to (and creating a savepoint for every execute
attempt), and silently encouraging SQL that will fail when fed to Postgres
through any other interface.
- --
Greg Sabino Mullane greg@xxxxxxxxxxxx
End Point Corporation
PGP Key: 0x14964AC8 200907141125
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----
iEYEAREDAAYFAkpcpGMACgkQvJuQZxSWSsjr1ACgjLWM4EurT9V+wXLXO83A+7pE
BPYAoKfYCl+6ywnOoQW4OOlKEP1YID0D
=QmVQ
-----END PGP SIGNATURE-----
--
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
