On Fri, May 08, 2009 at 04:02:29PM +0200, Daniel Verite wrote: > Tim Bunce wrote: > >> So you're okay with breaking previously working, and prefectly valid, > DBI code? > > I think the rationale is that such code was working by virtue of how > prepare() was implemented in DBD::Pg, but was not "valid" nonetheless, as > outlined with this example: > http://archives.postgresql.org/pgsql-general/2005-11/msg00339.php 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. The example that started this thread was that this valid statement worked: prepare("CREATE TEMP TABLE foo(...); INSERT INTO foo(1, 1); INSERT INTO foo(2, 2);") but this valid statement didn't: prepare(" INSERT INTO foo(1, 1); INSERT INTO foo(2, 2);") My argument is that both calls should return statement handles. The DBI user should not be exposed to the inner-workings and limitations of the support for server-side prepare. If a server-side prepare is attempted and fails because it's a kind of statement that can't be server-side prepared then DBD::pg should fallback to a client-side prepare. It does not matter that this may mean some invalid statements are caught by prepare() and others by execute(). The DBI spec has always allowed for that. Tim. 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. -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
