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
---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
