At 10:47 PM 04-01-2001 -0500, you wrote:
>Lincoln Yeoh <lyeoh@pop.jaring.my> writes:
>> Basically LISTEN doesn't wait.
>
>LISTEN has nothing to do with waiting. It merely informs the backend
>of your interest in subsequently receiving notices of a particular type.
>Perhaps you should think of it as like signal(2).
My fault - poor phrasing.
>See
>http://www.postgresql.org/devel-corner/docs/postgres/libpq-notify.htm
>but in brief the idea is:
>
>1. The outer event loop of your application uses select() to wait on
>the PQsocket() fd as well as any other interesting fds.
>
>2. When you see input ready on the PQsocket() fd, call PQconsumeInput(),
>then check PQnotifies().
>
>3. Also check PQnotifies() after any PQexec(), to see if notify messages
>came in during the query.
>
>Keep in mind also that notifications are only delivered when you are
>not within a transaction block (BEGIN/END).
Uhoh, since I'm using perl does that mean I have to patch DBI and Pg::DBD?
And worse - turn off transactions.
Would it be viable idea to add a WAIT command/statement for higher level
access (e.g. "SQL" level access to this feature)?
e.g.
WAIT "blahblahblah";
where it will wait until a NOTIFY "blahblahblah".
That'll be real nice to have :). If I start messing about with PQstuff I'll
probably screw up somewhere.
Thanks anyway,
Link.
