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 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend