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