Are there any plans to commit these libpq-events changes this fest?
http://archives.postgresql.org/pgsql-hackers/2008-09/msg01109.php
I wanted to release an updated libpqtypes but am waiting on the above
patch. If not, I'll release it now.
--
Andrew Chernow
eSilo, LLC
every bit counts
Andrew Chernow [EMAIL PROTECTED] writes:
Are there any plans to commit these libpq-events changes this fest?
Sorry about that, I got distracted. Will look at it shortly.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make
Andrew Chernow [EMAIL PROTECTED] 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
Tom Lane wrote:
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
I attached a patch. You have to copy the events in PQmakeEmptyPGResult
On Fri, Sep 19, 2008 at 2:14 PM, Andrew Chernow [EMAIL PROTECTED] wrote:
BTW, the event system might be an alternative solution for PGNoticeHooks
(PGEVT_NOTICE).
Another possible use of the event hooks -- just spitballing here -- is
to generate an event when a notification comes through (you
BTW, why are all the conn parameters to events declared const? Isn't
the reason for passing them in mainly to give the event proc a chance
to issue queries?
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your
Tom Lane wrote:
BTW, why are all the conn parameters to events declared const? Isn't
Because it looked prettier? Kidding. No idea, do you want me to change
that or do you want to?
the reason for passing them in mainly to give the event proc a chance
to issue queries?
Partly. You
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
BTW, why are all the conn parameters to events declared const? Isn't
Because it looked prettier? Kidding. No idea, do you want me to change
that or do you want to?
I'll fix it; it's hardly worth passing a patch around for.
Andrew Chernow [EMAIL PROTECTED] writes:
I attached a patch. You have to copy the events in PQmakeEmptyPGResult
because there is no where else to do this, other than copyresult but
that is different because it copies from a result not a conn.
Applied ...
PQgetResult now calls
Merlin Moncure [EMAIL PROTECTED] writes:
On Fri, Sep 19, 2008 at 2:14 PM, Andrew Chernow [EMAIL PROTECTED] wrote:
BTW, the event system might be an alternative solution for PGNoticeHooks
(PGEVT_NOTICE).
Another possible use of the event hooks -- just spitballing here -- is
to generate an
Now, it's questionable how tense we need to be about that as long as
event proc failure aborts calling of later event procs. That means
that procs have to be robust against getting DESTROY with no CREATE
calls in any case. Should we try to make that less uncertain?
I attached a patch
Andrew Chernow wrote:
Now, it's questionable how tense we need to be about that as long as
event proc failure aborts calling of later event procs. That means
that procs have to be robust against getting DESTROY with no CREATE
calls in any case. Should we try to make that less
Andrew Chernow [EMAIL PROTECTED] writes:
Now, it's questionable how tense we need to be about that as long as
event proc failure aborts calling of later event procs. That means
that procs have to be robust against getting DESTROY with no CREATE
calls in any case. Should we try to make that
Tom Lane wrote:
Some thought would need to be given to how that interacts with
RESULTCOPY. Presumably on the destination side, RESULTCOPY is the
equivalent of RESULTCREATE, ie, don't DESTROY if you didn't get COPY.
But what of the source side? Arguably you shouldn't invoke COPY on
events that
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
Some thought would need to be given to how that interacts with
RESULTCOPY. Presumably on the destination side, RESULTCOPY is the
equivalent of RESULTCREATE, ie, don't DESTROY if you didn't get COPY.
But what of the source side?
Andrew Chernow wrote:
New patch following our discussion with updated docs.
few logical errors). I don't think it makes sense to do it
otherwise, it would be like calling free after a malloc failure.
I can live with that definition, but please document it.
To build on this analogy,
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? This seems a rather
odd asymmetry, particularly in view of the fact that a RESULTDESTROY
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
Andrew Chernow [EMAIL PROTECTED] writes:
Tom Lane wrote:
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
Andrew Chernow [EMAIL PROTECTED] writes:
Yeah. Good point. I fixed it to always fire events.
Applied with editorial revisions --- I don't think I changed any
functionality, but I fixed a number of corner-case bugs and
editorialized on style a bit.
The general question of symmetry between
Andrew Chernow escribió:
/*
* PQmakeEmptyPGresult
* returns a newly allocated, initialized PGresult with given status.
* If conn is not NULL and status indicates an error, the conn's
* errorMessage is copied.
*
* Note this is exported --- you wouldn't think an
Andrew Chernow escribió:
Alvaro Herrera wrote:
Andrew Chernow escribió:
* PQclear -
* free's the memory associated with a PGresult
*/
I'd add a comment here stating why the event name is not deallocated;
otherwise it just looks like it's being leaked.
The event name is
22 matches
Mail list logo
