Message-ID: <482CD76E.6000202@esilo.com>
Date: Thu, 15 May 2008 20:38:06 -0400
From: Andrew Chernow <ac@esilo.com>
User-Agent: Thunderbird 2.0.0.14 (Windows/20080421)
MIME-Version: 1.0
To: Tom Lane <tgl@sss.pgh.pa.us>
CC: Merlin Moncure <mmoncure@gmail.com>, Andrew Dunstan <andrew@dunslane.net>,
	Alvaro Herrera <alvherre@commandprompt.com>,
	"Patches (PostgreSQL)" <pgsql-patches@postgresql.org>
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> <482C77E5.1060500@esilo.com>
	<9458.1210875556@sss.pgh.pa.us> <482C82BA.3090100@esilo.com>
	<9867.1210877054@sss.pgh.pa.us>
In-Reply-To: <9867.1210877054@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:
>> Which callback do we use as the key?  Currently, none are required (only 
>> the name was required).  We have to choose one callback that must be 
>> provided.
> 
> What?  I thought what you wanted back was the void * pointer that had
> been registered with a particular callback function.  So you use that
> callback function.  If it's not actually registered, you get a NULL.
> 
>> This is what is passed to PQaddObjectHooks, along with a conn:
> 
> This is all wrong IMHO, not least because it creates ABI problems if you
> want to add another hook type later.  Register each hook separately, eg
> 
> typedef void (*PGCRHook) (PGconn *conn, void *passthrough);
> 
> void PQregisterConnResetHook(PGconn *conn, PQCRHook func, void *passthrough);
> 
> ... repeat for each possible hook ...
> 
> 			regards, tom lane
> 
> 

I am starting to think we have not clarified what it is we are trying to 
do; maybe hook is the wrong terminology.

We need to add members to a conn and result, that's pretty much it.  To 
do this, an api user can register callbacks to receive notifications 
about created/destroyed states of objects.  PQhookData is just like 
PQerrorMessage in that both are public accessor functions to private 
object data.  The difference is that there can be more than one hookData 
"dynamic struct member" on a conn/result at a time, unlike errorMessage; 
  thus the need for an additional "lookup" value when getting hook data 
(what was hookName).

A solution is to only have one function with an eventId, instead of a 
register function per event.  I am playing with using the name 'event' 
rather than hook.

typedef enum
{
   PQEVTID_INITDATA,
   PQEVTID_CONNRESET,
   // resultcreate, resultcopy, etc...
} PGobjectEventId;

typedef void *(*PGobjectEventProc)(PGobjectEventId evtId, ...);

int PQregisterObjectEventProc(PGconn*, PGobjectEventProc);

// no more key (hookName), use PGobjectEventProc address
void *PQeventData(PGconn *, PGobjectEventProc);
void *PQresultEventData(PGresult *, PGobjectEventProc);

Now there is just one libpq register function and an enum; very 
resilient to future additions and ABI friendly.  The API user will 
follow a convention of: if you don't care about an event or don't know 
what it is, just return NULL from the eventProc function (ignore it).

The implementation of a PGobjectEventProc would most likely be a switch 
on the PGobjectEventId with a couple va_arg() calls (which would be very 
well documented).

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