Re: libpq object hooks

Tom Lane wrote:
> "Merlin Moncure" <mmoncure(at)gmail(dot)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
>
>

There can be cases to use the same callbacks, although unlikely. To
completely avoid collisions, the below would work:

Use the address of a static, maybe an 'int', as a hook hanlde. Provide
the user with a macro that can make a hook handle.

typedef void *PGhookHandle;

// Declare an int and point "tokname" at it. The value doesn't
// matter, its the pointer address we are interested in.
#define PQ_MAKE_HOOK_HANDLE(tokname) \
static int hh__ ## tokname = 0; \
static const PGhookHandle tokname = &hh__ ## tokname

As an example, here is what libpqtypes would do:

// libpqtypes hooks.c
PQ_MAKE_HOOK_HANDLE(pqthookhandle);

Now the handle replaces the hookName. The "const char *hookName" member
of the PQobjectHooks structure is changed to "const PGhookHanlde
hookHandle". This allows for all the flexibility of a const char * w/o
the collision issues.

// these function prototypes change as well
void *PQhookData(PGconn *, const PGhookHandle);
void *PQresultHookData(PGresult *, const PGhookHandle);

We will send in an updated patch.

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