To: "Merlin Moncure" <mmoncure@gmail.com>
cc: "Andrew Dunstan" <andrew@dunslane.net>,
	"Alvaro Herrera" <alvherre@commandprompt.com>,
	"Patches (PostgreSQL)" <pgsql-patches@postgresql.org>,
	"Andrew Chernow" <ac@esilo.com>
Subject: Re: libpq object hooks 
In-reply-to: <b42b73150805150852m7b3c28fai2d7a4497c84118b2@mail.gmail.com> 
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>
Comments: In-reply-to "Merlin Moncure" <mmoncure@gmail.com>
	message dated "Thu, 15 May 2008 11:52:21 -0400"
Date: Thu, 15 May 2008 12:09:31 -0400
Message-ID: <6044.1210867771@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

"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.

			regards, tom lane