Tom Lane wrote:
"Merlin Moncure" <[EMAIL PROTECTED]> 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/
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
