On Thu, May 15, 2008 at 8:38 PM, Andrew Chernow <[EMAIL PROTECTED]> 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 callbacks..it'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. merlin -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
