agora inbox for [email protected]  

help / color / mirror / Atom feed

From: Andrew Chernow <[email protected]>
To: Tom Lane <[email protected]>
Cc: Merlin Moncure <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: Patches (PostgreSQL) <[email protected]>
Subject: Re: libpq object hooks
Date: Thu, 15 May 2008 14:36:42 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>

Tom Lane wrote:
> Andrew Chernow <[email protected]> writes:
>> There can be cases to use the same callbacks, although unlikely.  To 
>> completely avoid collisions, the below would work:
> 
> Still looks like overdesign to me.  If we use the hook function address
> we solve the problem with no extra notation and no extra storage.
> 
> Note that if you want N fixed keys, you can just have N hook functions
> (all calling a shared workhorse routine, no doubt).  So your proposal
> adds no functionality whatever if the usage involves a fixed number of
> static handles.  Now it could possibly allow a variable-at-runtime
> number of handles, but I'd want to see a worked-out use case before
> designing for that much complexity.  In particular, it seems to me that
> the problem would then shift to how do you know which handle to use for
> the lookup, thus you've just introduced another layer of complexity
> without buying anything.
> 
> I think the typical use case is just that you need to distinguish "your"
> hook from anyone else's hooks, so the function address is plenty
> sufficient.
> 
> It should also be noted that this whole problem *can* be solved without
> any PQhookData at all: as long as you have hooks to get control at
> creation and destruction of PGconns and PGresults, you can maintain your
> own index data structure.  I'm willing to grant some amount of extra
> API-stuff to save users having to do that in simple cases, but I don't
> think we need to try to support infinitely complex cases.
> 
> 			regards, tom lane
> 
> 

Okay.  No problem over here.

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.  Maybe initHookData() must be provided?  If the end-user 
doesn't need it they can just return NULL.

This is what is passed to PQaddObjectHooks, along with a conn:

typedef struct
{
   //char *name; REMOVED

   void *data;

   /* Invoked when PQsetObjectHook is called.  The pointer returned
    * by the hook implementation is stored in the private storage of
    * the PGconn, accessible via PQhookData(PGconn*).  If no
    * storage is needed, return NULL or set this hook to NULL.
    */
   void *(*initHookData)(const PGconn *conn);

   /* Invoked on PQreset and PQresetPoll */
   void (*connReset)(const PGconn *conn);

   /* Invoked on PQfinish. */
   void (*connDestroy)(const PGconn *conn);

   /* Invoked on PQgetResult, internally called by all exec funcs */
   void *(*resultCreate)(const PGconn *conn, const PGresult *result);

   /* Invoked on PQcopyResult */
   void *(*resultCopy)(PGresult *dest, const PGresult *src);

   /* Invoked when PQclear is called */
   void (*resultDestroy)(const PGresult *result);
} PGobjectHooks;

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

view thread (64+ messages)  latest in thread

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: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: libpq object hooks
  In-Reply-To: <[email protected]>

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

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