Just my 2 cents here. I agree with tom that the curent behevior for the v3
protocol is the right one. I use "On demand" preparation. The first time a
statement is needed for a specific connection, it is prepared and the client
keep track of that (reusing the prepared statement for subsequent calls). If
the transaction where the statement is prepared is aborted for whatever reason,
the prepared statement MUST remain valid for this to work, otherwise I need to
track if the transaction where the statement have been prepared commited or not
and invalidate it if it's not the case. This is a waste of time : tracking
transaction state / preparing a statement more than once. The only case where
rolling back a prepared statement can make sense is with DDL modifying
underlying objects (tables, index...).
If this behavior is changed things will breaks for some people.
cyril
----- Message d'origine -----
De : mailto:tgl@sss.pgh.pa.us
Emission : 24/06/2004 16:26:33
> "Jeroen T. Vermeulen" <jtv@xs4all.nl> writes:
> > I think we're talking at cross purposes here... If the client doesn't use
> > explicit transactions, as you say is common, then you're obviously not
> > defining prepared statements inside explicit transactions either.
>
> This whole discussion seems to be considering only the case of PREPAREs
> issued as SQL statements, by a programmer who is fully cognizant of
> where he's beginning and ending transactions.
>
> The issue I was trying to raise at the beginning of the thread was: what
> about prepared statements created by client libraries (think JDBC for
> instance) using the V3 protocol Parse message? Rolling back a
> successful prepare because of a later transaction failure seems like
> exactly not what such a library would want.
>
> regards, tom lane
