>> To build on this analogy, PGEVT_CONNRESET is like a realloc. Meaning,
>> the initial malloc "PGEVT_REGISTER" worked by the realloc
>> "PGEVT_CONNRESET" didn't ... you still have free "PGEVT_CONNDESTROY" the
>> initial. Its documented that way. Basically if a register succeeds, a
>> destroy will always be sent regardless of what happens with a reset.
> I attached the wrong patch. I'm sorry.
I had a further thought about this: after applying this patch, it is
essentially useless for the exposed PQmakeEmptyPGresult function to
copy events into the result. If it doesn't give them a RESULTCREATE
call, then they cannot receive RESULTCOPY or RESULTDESTROY either,
so they might as well not be there.
The argument for not having PQmakeEmptyPGresult fire RESULTCREATE still
makes sense, but I am thinking that maybe what we ought to do is expose
a new function named something like PQfireResultCreateEvents() that just
does that. This would allow an application to exactly emulate what
PQgetResult does: make an empty PGresult, fill it, then fire the create
events.
I'll go ahead and apply this patch in a little bit, but if you concur
with the above reasoning, please put together a followon patch to add
such a function.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
No comments:
Post a Comment