Re: Weird prepared stmt behavior

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/