Message-ID: <48D072E3.6010703@esilo.com>
Date: Tue, 16 Sep 2008 23:00:51 -0400
From: Andrew Chernow <ac@esilo.com>
User-Agent: Thunderbird 2.0.0.16 (Windows/20080708)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
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)
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>
In-Reply-To: <27615.1221619326@sss.pgh.pa.us>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Tom Lane wrote:
> Andrew Chernow <ac@esilo.com> 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 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.

Is there a use case you think requires the opposite behavior?

> odd asymmetry, particularly in view of the fact that a RESULTDESTROY
> event will occur for error results.  And surely we do not need to
> micro-optimize error cases for speed.
> 

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.

But before I fix this and put a patch up, please let me know if you prefer the 
opposite behavior ... trigger events on success or failure (including connreset).

-- 
Andrew Chernow
eSilo, LLC
every bit counts
http://www.esilo.com/