"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 gen
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 PQfireR
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.
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 a
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
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
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
bec
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. Bas
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
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
http:/
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, PGEVT
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 sid
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:
>>> 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 t
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 uncert
> 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 patc
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 RE
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 w
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 it
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
ev
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.
>
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
22 matches
Mail list logo
