Message-ID: <482C7778.40707@dunslane.net>
Date: Thu, 15 May 2008 13:48:40 -0400
From: Andrew Dunstan <andrew@dunslane.net>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.8.0.12) Gecko/20071019 Fedora/1.0.9-3.fc6 pango-text
	SeaMonkey/1.0.9
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Merlin Moncure <mmoncure@gmail.com>,
	Alvaro Herrera <alvherre@commandprompt.com>,
	"Patches (PostgreSQL)" <pgsql-patches@postgresql.org>,
	Andrew Chernow <ac@esilo.com>
Subject: Re: libpq object hooks
References: <b42b73150804301323i18b00019i62e765708abb65aa@mail.gmail.com>
	<482A58D8.2030205@dunslane.net>
	<20080514043313.GS6966@alvh.no-ip.org>
	<482AD896.4000504@dunslane.net> <19342.1210776271@sss.pgh.pa.us>
	<b42b73150805150852m7b3c28fai2d7a4497c84118b2@mail.gmail.com>
	<6044.1210867771@sss.pgh.pa.us>
In-Reply-To: <6044.1210867771@sss.pgh.pa.us>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit


Tom Lane wrote:
> "Merlin Moncure" <mmoncure@gmail.com> writes:
>   
>> The problem is the functions PQhookData(conn, hookname) and
>> PQresultHookData(result, hookName).  We need these to work in
>> functions that are not callbacks.  If we eliminate hookname
>> completely, there is no way for libpq to know which private state we
>> are asking for.
>>     
>
> Well, depending on a hook name for this is broken-by-design anyway,
> because there is no way for two independently written libraries to
> be sure they don't choose conflicting hook names.  So the need for
> a hook name has to go away.
>
> It might work to use the address of the hook callback function as
> a key for retrieving the associated void * pointer.  You'd need to
> not register the same callback function more than once per object,
> but from what I gather here you don't need to.
>
> 			
>   

Or else have the library return a unique handle when registering hooks, 
rather than supplying a hook name.

cheers

andrew