On Sun, May 02, 2004 at 10:08:50AM +1200, Oliver Jowett wrote:
> If PREPARE can roll back, the driver must maintain a set of all
> statements that were sucessfully PREPAREd in the current transaction,
> and fix up the corresponding query object state whenever a transaction
> rolls back.
>
> From that point of view, it's much simpler to keep PREPARE (or at least
> Parse) as it currently is. I suspect the same argument applies to any
> interface layer that uses PREPARE or Parse automatically.
Exactly.
Tom, will work these two scenarios:
1/ I have web application that uses persistent connetions to PostgreSQL
backend. After the connection opening the application prepares all
queries and the rest of the application code uses EXECUTE statement
only. It means the EXECUTE statemens are used in next arbitrary
transactions.
2/ The other way which my application uses is "prepare query first
time when some code needs it" -- and it's independend on actual
transaction of course. I use this way now, beacuse it's more
effective for me than prepare all queries after the connection startup.
If I good understand your idea the case 1/ will work, but case 2/ not.
I have no care about
BEGIN;
CREATE TABLE xxx (id serial);
PREPARE q AS SELECT * FROM xxx;
ABORT;
EXECUTE q;
ERROR: relation with OID 38242 does not exist
because I can detect it by error message and it's too academic problem
for me. I don't change DB schema in stable and production server and I
think ALTER/DROP/CREATE is nothing often in running and good designed
databases.
Karel
--
Karel Zak <zakkr@zf.jcu.cz>
http://home.zf.jcu.cz/~zakkr/