From: | "Cyril VELTER" <cyril(dot)velter(at)metadys(dot)com> |
---|---|
To: | alvherre(at)dcc(dot)uchile(dot)cl |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | [Re] Re: [Re] Re: PREPARE and transactions |
Date: | 2004-06-24 19:53:25 |
Message-ID: | 0-38162823940-2674-52058@CFGEM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
De : mailto:alvherre(at)dcc(dot)uchile(dot)cl
Emission : 24/06/2004 18:59:15
> On Thu, Jun 24, 2004 at 05:11:48PM +0200, Cyril VELTER wrote:
> >
> > 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 why I proposed originally to keep the non-transactional behavior
> for Parse messages, but transactional for SQL PREPARE. The latter can
> be said to be inside the transaction and should behave like so. I think
> this lowers the surprise factor.
Yes, as long as there is a libpq call which allow to prepare a statement
without using the SQL PREPARE, which AFAIK does not exist today. something like
PQprepare(conn,name,statement,nParams,paramTypes[]) would do. I just checked my
code and while I use PQexecPrepared, I use the SQL PREPARE to prepare the
statement as there is no other way with libpq.
cyril
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2004-06-24 20:19:36 | Re: PREPARE and transactions |
Previous Message | Tom Lane | 2004-06-24 18:59:14 | Re: Compiling libpq with VisualC |