Skip site navigation (1) Skip section navigation (2)

Re: PREPARE and transactions

From: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Merlin Moncure <merlin(dot)moncure(at)rcsonline(dot)com>,pgsql-hackers(at)postgresql(dot)org, Alvaro Herrera <alvherre(at)dcc(dot)uchile(dot)cl>
Subject: Re: PREPARE and transactions
Date: 2004-06-25 14:20:53
Message-ID: 20040625142052.GC74396@xs4all.nl (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Jun 25, 2004 at 10:02:29AM -0400, Tom Lane wrote:
 
> It occurs to me that a lot of the problem would go away if we allowed
> DEALLOCATE of a nonexistent statement to not be an error (seems like
> a NOTICE would be be plenty).  Then you could just unconditionally
> DEALLOCATE anything you were about to PREPARE, if you weren't entirely
> sure whether it already existed.

That would be an improvement anyway, I think--especially if the backend
could keep deallocated plans around a little longer in case they got
re-prepared soon after.  That way the client can ensure not only that the
statement doesn't exist, but also that it _does_ exist, without incurring
prohibitive cost.  And without going through an "if" construct too.

OTOH the problem then remains that we've got semantically significant work
escaping from transactions, but in all other ways being presented as a
regular bracketed operation.  To me it's a bit like a C function returning
a pointer to one of its own stack variables!


Jeroen


In response to

pgsql-hackers by date

Next:From: Tom LaneDate: 2004-06-25 15:10:17
Subject: Re: Compile failure with SSL
Previous:From: Tom LaneDate: 2004-06-25 14:02:29
Subject: Re: PREPARE and transactions

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group