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

From Alvaro Herrera
Subject Re: Weird prepared stmt behavior
Date
Msg-id 20040501172047.GE2333@dcc.uchile.cl
Whole thread Raw
In response to Re: Weird prepared stmt behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Weird prepared stmt behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Apr 30, 2004 at 09:44:52PM -0400, Tom Lane wrote:
> Alvaro Herrera <alvherre@dcc.uchile.cl> writes:
> > Is this expected?  If so, why?  I'd expect the prepared stmt to be
> > deallocated.
> 
> prepare.c probably should have provisions for rolling back its state to
> the start of a failed transaction ... but it doesn't.
> 
> 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.

Right now there is no distinction between a PREPARE prepared statement
and a protocol-level one.  If we want to have the v3proto's statements
behave different from PREPARE's, it's just a matter of adding a new
field into the PreparedStatement.  I can do that and make them behave
different if people think this is how it should be.

I don't really have an opinion on whether protocol-level should behave
different.  What do people think?

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
Bob [Floyd] used to say that he was planning to get a Ph.D. by the "green
stamp method,", namely by saving envelopes addressed to him as 'Dr. Floyd'.
After collecting 500 such letters, he mused, a university somewhere in
Arizona would probably grant him a degree.              (Don Knuth)


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Current CVS tip segfaulting
Next
From: Tom Lane
Date:
Subject: Re: mingw configure failure workaround