In case anyone's wondering why I'm replying to an article that's nearly a
year old, it came up in a search while I was looking for the more recent
LISTEN/NOTIFY thread...
In article <7373.1104169267@sss.pgh.pa.us>,
Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Sean Chittenden <sean@chittenden.org> writes:
>> The async interface is nice, but not really useful to me as it requires
>> polling, instead of unblocking when an event comes through, which would
>> create a vastly more real time interface that should be easier on the
>> database.
>
>BTW, this is nonsense; the backend sends a message exactly when the
>NOTIFY occurs. It may well be that libpq needs some work to make it
>easier to wait for a NOTIFY without polling, but again there isn't a
>reason to clutter the server-side code with it.
One thing that persistently annoys me about using LISTEN in clients
is that much of the time I'm not using libpq directly, but some layer
above libpq that implements a generic SQL interface. These interfaces
generally assume that SQL calls are synchronous and blocking unless
you use some kind of escape to the lower-level driver, and in a few
environments there is no such escape at all.
I'd really like to have something that looks as much like an SQL statement
as possible, which blocks until a NOTIFY event or a timeout occurs. If not
a stand-alone SQL command then at least a function.
In one case where I really needed this, I implemented a really *ugly*
PL/PerlU function that did the following:
open a new client connection (with caching) to the server fromthe server's own backend
set up appropriate LISTEN commands,
go to sleep on a poll() from the file descriptor,
then return immediately after poll() does.
Thankfully this particular application was not required to scale beyond
a half-dozen clients!
--
Zygo Blaxell (Laptop) <zblaxell@feedme.hungrycats.org>
GPG = B203 9402 B0E7 0F20 3B74 B13C DFBC C916 4395 FD03