pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Andrew Chernow <ac@esilo.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Merlin Moncure <mmoncure@gmail.com>
Cc: Andrew Dunstan <andrew@dunslane.net>
Cc: Alvaro Herrera <alvherre@commandprompt.com>
Cc: Patches (PostgreSQL) <pgsql-patches@postgresql.org>
Subject: Re: libpq object hooks
Date: Thu, 15 May 2008 13:50:29 -0400
Message-ID: <482C77E5.1060500@esilo.com> (raw)
In-Reply-To: <6044.1210867771@sss.pgh.pa.us>
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>

Tom Lane wrote:
> "Merlin Moncure" <mmoncure@gmail.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/



view thread (45+ messages)  latest in thread

Message-ID: <482C77E5.1060500@esilo.com>
Permalink:  ../482C77E5.1060500@esilo.com/
Also on:    postgresql.org/message-id/482C77E5.1060500@esilo.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: ac@esilo.com, tgl@sss.pgh.pa.us, mmoncure@gmail.com, andrew@dunslane.net, alvherre@commandprompt.com, pgsql-patches@postgresql.org
  Subject: Re: libpq object hooks
  In-Reply-To: <482C77E5.1060500@esilo.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox