From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Chernow <ac(at)esilo(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com> |
Subject: | Re: [PATCHES] libpq events patch (with sgml docs) |
Date: | 2008-09-17 04:36:53 |
Message-ID: | 454.1221626213@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers pgsql-patches |
Andrew Chernow <ac(at)esilo(dot)com> 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 RESULTCREATE and RESULTDESTROY
callbacks is still bothering me. As committed, PQmakeEmptyPGresult
will copy events into its result, but not fire RESULTCREATE for them
... but they'll get RESULTDESTROY when it's deleted. Is that what we
want? I don't have a lot of faith that PQgetResult is the only place
inside libpq that needs to fire RESULTCREATE, either.
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?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2008-09-17 04:48:29 | Re: Common Table Expressions (WITH RECURSIVE) patch |
Previous Message | Andrew Chernow | 2008-09-17 03:59:44 | Re: [PATCHES] libpq events patch (with sgml docs) |
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-09-17 08:31:45 | Re: [HACKERS] Infrastructure changes for recovery |
Previous Message | Andrew Chernow | 2008-09-17 03:59:44 | Re: [PATCHES] libpq events patch (with sgml docs) |