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

Re: libpq object hooks

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Merlin Moncure" <mmoncure(at)gmail(dot)com>
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 14:59:08
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackerspgsql-patches
"Merlin Moncure" <mmoncure(at)gmail(dot)com> writes:
>> 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.

I don't think varargs callbacks are a good idea at all.  Please adjust
this to something that doesn't do that.  Also, haven't you forgotten
the passthrough void *?

If you really want only one callback function, perhaps what would work

typedef void (*PGeventProc) (PGeventId eventId, const void *eventInfo,
                             void *passthrough);

int PQregisterEventProc(PGconn *conn, PGeventProc proc, void *passthrough);

where eventInfo will point to one of several exported struct types
depending on the value of eventId.  With this approach, you can add
more fields to the end of any one such struct type without creating
ABI issues.  I have little confidence in being able to make similar
changes in a varargs environment.

Also, even if varargs are safe they'd be notationally unpleasant
in the extreme.  varargs are just a PITA to work with --- you'd have
to do all the decoding in the first-level hook routine, even for
items you weren't going to use.  With something like the above
all you need is a switch() and some pointer casts.

			regards, tom lane

In response to


pgsql-hackers by date

Next:From: Merlin MoncureDate: 2008-05-16 15:13:43
Subject: Re: libpq object hooks
Previous:From: Tom LaneDate: 2008-05-16 14:35:05
Subject: Re: deadlock while doing VACUUM and DROP

pgsql-patches by date

Next:From: Bruce MomjianDate: 2008-05-16 15:04:21
Subject: Re: libpq thread-locking
Previous:From: Magnus HaganderDate: 2008-05-16 14:35:20
Subject: Re: libpq thread-locking

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