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: <48D072E3.6010703@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>
Comments: In-reply-to Andrew Chernow <ac@esilo.com>
	message dated "Tue, 16 Sep 2008 23:00:51 -0400"
Date: Tue, 16 Sep 2008 23:40:17 -0400
Message-ID: <28673.1221622817@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Andrew Chernow <ac@esilo.com> 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 does), just to have it PQclear'd once the 
> user gets the dead result back.  I guess we figured an error result typically 
> has a short life-span, not very useful outside of indicating an error.

Well, you could do a PQresultStatus and skip any prep work if you
actually saw a need to micro-optimize such cases.

> It is odd.  Actually, it looks like a bug to me.  PQgetResult is the
> behavior we were after, don't trigger the event if the creation
> failed.  Same thing occurs during a conn reset.  Looks like PQclear
> needs to check resultStatus before it triggers RESULTDESTROY events.

If you did that, then you WOULD have a bug.  Consider case where you
successfully init two events, and the third one fails.  You'll now
change the result's status to ERROR.  If you don't RESULTDESTROY
then the first two events will leak whatever storage they allocated.

The reason I suggested not being conditional about the init call was
to reduce the probability of bugs of similar ilks associated with
an event proc assuming that it could only get a DESTROY call for
something it had seen CREATEd --- for example, if it were frobbing
a reference count for some long-lived data, it could very easily
screw up the reference count that way.  I suppose that the risk of
an earlier event proc failing means it has to cope with that case
anyway, but I don't think it's a particularly good idea to have
arbitrary asymmetries increasing the odds of a problem.

			regards, tom lane