Re: Weird prepared stmt behavior - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Weird prepared stmt behavior
Date
Msg-id 20040503195100.GF30007@dcc.uchile.cl
Whole thread Raw
In response to Re: Weird prepared stmt behavior  (Greg Stark <gsstark@mit.edu>)
Responses Re: Weird prepared stmt behavior  (Greg Stark <gsstark@mit.edu>)
List pgsql-hackers
On Mon, May 03, 2004 at 03:18:37PM -0400, Greg Stark wrote:
> 
> Tom Lane <tgl@sss.pgh.pa.us> writes:
> 
> > Before jumping into doing that, though, I'd want to have some
> > discussions about the implications for the V3 protocol's notion of
> > prepared statements.  The protocol spec does not say anything that
> > would suggest that prepared statements are lost on transaction rollback,
> > and offhand it seems like they shouldn't be because the protocol is
> > lower-level than transactions.
> 
> Woah, that would totally defeat the purpose of prepared statements.
> 
> The idea is that an OLTP system can prepare all the statements it will ever
> need at startup time. Then simply execute them with various parameters as
> needed.

I don't see how this collides with the ideas presented so far.  The JDBC
driver wants the same: they want to prepare some statements and be able
to use them later in the session.  They don't want to be paying
attention to which prepares were committed and which ones weren't.

> Using a good driver like Perl's DBI this just means using something like
> prepare_cached() instead of prepare().

Then prepare_cached could send a v3 Prepare and assume the statement
will be available for the rest of the session.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end." (2nd Commandment for C programmers)


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Fixed directory locations in installs
Next
From: Peter Eisentraut
Date:
Subject: Re: Fixed directory locations in installs