| 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 |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2004-06-25 15:10:17 | Re: Compile failure with SSL |
| Previous Message | Tom Lane | 2004-06-25 14:02:29 | Re: PREPARE and transactions |