To: Andrew Chernow <ac@esilo.com>
cc: Alvaro Herrera <alvherre@commandprompt.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>,
	Merlin Moncure <mmoncure@gmail.com>
Subject: Re: [PATCHES] libpq events patch (with sgml docs) 
In-reply-to: <48D080B0.6070104@esilo.com> 
References: <48C18533.2000204@esilo.com>
	<20080905192215.GK4353@alvh.no-ip.org> <48C18B48.509@esilo.com>
	<20080905194853.GL4353@alvh.no-ip.org> <48C191A7.3000205@esilo.com>
	<20080905201504.GM4353@alvh.no-ip.org>
	<48C19759.90402@esilo.com> <27615.1221619326@sss.pgh.pa.us>
	<48D072E3.6010703@esilo.com> <28673.1221622817@sss.pgh.pa.us>
	<48D080B0.6070104@esilo.com>
Comments: In-reply-to Andrew Chernow <ac@esilo.com>
	message dated "Tue, 16 Sep 2008 23:59:44 -0400"
Date: Wed, 17 Sep 2008 00:36:53 -0400
Message-ID: <454.1221626213@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Andrew Chernow <ac@esilo.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