Re: LISTEN/NOTIFY enhancement: Portable signal handling?

>> 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.

It's asynchronous with regards to client delivery of the message.
Sending of the NOTIFY message is synchronous, but delivery to the
client is not. I don't see how it could be any other way in
PostgreSQL. libpq(3) actually has a reasonable interface that relies
on the developer to block on the fd as described here:

http://developer.postgresql.org/docs/postgres/libpq-notify.html

The problem is that this doesn't work in pl/*, which is the problem I
was trying to address. *shrug* -sc

--
Sean Chittenden