Re: [HACKERS] Weird prepared stmt behavior

From: Karel Zak <zakkr(at)zf(dot)jcu(dot)cz>
To: Oliver Jowett <oliver(at)opencloud(dot)com>
Cc: alvherre(at)dcc(dot)uchile(dot)cl, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org, pgsql-jdbc(at)postgresql(dot)org
Subject: Re: [HACKERS] Weird prepared stmt behavior
Date: 2004-05-06 08:25:45
Message-ID: 20040506082544.GF6749@zf.jcu.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-jdbc

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(at)zf(dot)jcu(dot)cz>
http://home.zf.jcu.cz/~zakkr/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Gaetano Mendola 2004-05-06 08:35:00 Re: Postgres Optimization: IO and Data Organization
Previous Message Tony Reina 2004-05-06 08:22:45 Re: Function to do runtime relative directory mapping

Browse pgsql-jdbc by date

  From Date Subject
Next Message Carson Gross 2004-05-06 18:26:49 Where is the JDBC driver source?
Previous Message Barry Lind 2004-05-06 00:41:26 Re: Result Set Cursor Patch