De : mailto:[EMAIL PROTECTED]
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
---------------------------(end of broadcast)---------------------------
TIP 7: don't forget to increase your free space map settings
