Re: [PATCHES] libpq events patch (with sgml docs)

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

In response to

Responses

Browse pgsql-hackers by date

  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)

Browse pgsql-patches by date

  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)