Tom Lane wrote:
Andrew Chernow <[EMAIL PROTECTED]> 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
  // 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

Sent via pgsql-patches mailing list (
To make changes to your subscription:

Reply via email to