> > I would be fine with changing the lifetime if an EXECUTE failure did
not
> > abort the current transaction.  Then I could simply watch the return
> > code of the statement execution and prepare the statement on
> > demand...from my point of view, this would actually be the most
elegant
> > scenario.
> 
> BEGIN;
> 	... do something ... ;
> 	SUBBEGIN;
> 		EXECUTE ...;
> 		-- if it fails:
> 		-- SUBABORT;
> 		-- PREPARE ...;
> 		-- SUBBEGIN;
> 		-- EXECUTE ...;
> 		-- can continue as if nothing happened
> 	SUBCOMMIT;
> COMMIT;

This is not an option: this requires that every EXECUTE be wrapped with
a subtransaction.  This is a performance killer because it (at minimum)
triples my statement turnaround latency.

With the current behavior, you can guarantee certain behaviors by
wrapping PREPARE/DEALLOCATE... and I was eagerly anticipating your work
to do this.  I would much rather do that than be required to wrap every
single EXECUTE (recall that most of my I/O goes through prepared
statements).

Merlin

Sat, 26 Jun 2004 09:12:33 -0400
"Merlin Moncure" <merlin.moncure@rcsonline.com>
Re: PREPARE and transactions
On Sat, Jun 26, 2004 at 09:12:33AM -0400, Merlin Moncure wrote:

> > BEGIN;
> > 	... do something ... ;
> > 	SUBBEGIN;
> > 		EXECUTE ...;
> > 		-- if it fails:
> > 		-- SUBABORT;
> > 		-- PREPARE ...;
> > 		-- SUBBEGIN;
> > 		-- EXECUTE ...;
> > 		-- can continue as if nothing happened
> > 	SUBCOMMIT;
> > COMMIT;
> 
> This is not an option: this requires that every EXECUTE be wrapped with
> a subtransaction.  This is a performance killer because it (at minimum)
> triples my statement turnaround latency.

Ah, good point.

-- 
Alvaro Herrera (<alvherre[a]dcc.uchile.cl>)
"Linux transformï¿½ mi computadora, de una `mï¿½quina para hacer cosas',
en un aparato realmente entretenido, sobre el cual cada dï¿½a aprendo
algo nuevo" (Jaime Salinas)


Sat, 26 Jun 2004 13:28:23 -0400
Alvaro Herrera <alvherre@dcc.uchile.cl>
Re: PREPARE and transactions