Skip site navigation (1) Skip section navigation (2)

Re: libpq object hooks

From: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: "Andrew Chernow" <ac(at)esilo(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Alvaro Herrera" <alvherre(at)commandprompt(dot)com>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: libpq object hooks
Date: 2008-05-16 13:28:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
On Thu, May 15, 2008 at 8:38 PM, Andrew Chernow <ac(at)esilo(dot)com> wrote:
> 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).

> typedef void *(*PGobjectEventProc)(PGobjectEventId evtId, ...);
> int PQregisterObjectEventProc(PGconn*, PGobjectEventProc);
> void *PQeventData(PGconn *, PGobjectEventProc);
> void *PQresultEventData(PGresult *, PGobjectEventProc);

This provides what we need...a key to lookup the hook data without
using a string. Also, it reduces the number of exports (it's a little
easier for us, while not essential, to not have to register each
callback individually).  Also, this AFAICT does not have any ABI
issues (no struct), and adds less exports which is nice.  We don't
have to 'look up' the data inside the's properly passed
through as an argument.  While vararg callbacks may be considered
unsafe in some scenarios, I think it's a good fit here.

The most important part though is that it fits what we think is needed
to maintain the data we associate with the libpq with the proper
lifetime.  I'm not sure that everyone was on the same page in terms of
how this works...we may not have explained ourselves properly.  In our
defense, the interaction between libpq and a wrapping library like
libpqtypes is a bit involved and the 'best possible' way to link
things up did not necessarily suggest itself the first time out.

We would like to wrap this up into some form the community would
accept.  The event proc style of doing this is better than our initial
approach...faster and cleaner.  In fact, we are pleased with all the
changes that have come about due to community suggestions...there are
many positive results.


In response to


pgsql-hackers by date

Next:From: Alvaro HerreraDate: 2008-05-16 14:14:45
Subject: Re: deadlock while doing VACUUM and DROP
Previous:From: Kenneth MarshallDate: 2008-05-16 13:04:42
Subject: Re: [GSoC08]some detail plan of improving hash index

pgsql-patches by date

Next:From: Magnus HaganderDate: 2008-05-16 14:04:38
Subject: Re: libpq thread-locking
Previous:From: David FetterDate: 2008-05-16 05:38:38
Subject: Re: Patch to change psql default banner v6

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group