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
{
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/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
