Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> writes:
Missed that one. Good catch :) Update attached.
Looking at this now. Question: why does PQgetResult invoke the
RESULTCREATE event only for non-error results?
It didn't seem useful to have the eventproc implementation allocate its private
storage (or do whatever prep work it does), just to have it PQclear'd once the
user gets the dead result back. I guess we figured an error result typically
has a short life-span, not very useful outside of indicating an error.
Is there a use case you think requires the opposite behavior?
odd asymmetry, particularly in view of the fact that a RESULTDESTROY
event will occur for error results. And surely we do not need to
micro-optimize error cases for speed.
It is odd. Actually, it looks like a bug to me. PQgetResult is the behavior we
were after, don't trigger the event if the creation failed. Same thing occurs
during a conn reset. Looks like PQclear needs to check resultStatus before it
triggers RESULTDESTROY events.
But before I fix this and put a patch up, please let me know if you prefer the
opposite behavior ... trigger events on success or failure (including connreset).
--
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
