Re: [PATCHES] libpq events patch (with sgml docs) - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PATCHES] libpq events patch (with sgml docs)
Date
Msg-id 28666.1221840662@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PATCHES] libpq events patch (with sgml docs)  (Andrew Chernow <ac@esilo.com>)
Responses Re: [PATCHES] libpq events patch (with sgml docs)  (Andrew Chernow <ac@esilo.com>)
List pgsql-hackers
Andrew Chernow <ac@esilo.com> writes:
>> 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


pgsql-hackers by date:

Previous
From: "Robert Haas"
Date:
Subject: Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Next
From: Jan Urbański
Date:
Subject: Re: gsoc, oprrest function for text search take 2