About a month ago I wrote
> Yes, if anything were to be done along this line it'd also make sense
> to revise libpgtcl. I think it ought to work more like this:
> (a) the idle loop is invoked while waiting for a query response
> (so that a pg_exec statement behaves sort of like "tkwait");
> (b) a "listen" command is sent via a new pg_listen statement that
> specifies a callback command string. Subsequent notify responses
> can occur whenever a callback is possible.
> I suppose (a) had better be an option to pg_exec statements so that
> we don't break existing Tcl code...
I was a little startled to discover that pg_listen already exists
(it's not documented!). But the way things are currently set up,
the callbacks specified by pg_listen are executed only when the Tcl
script invokes the also-undocumented pg_notifies command.
pg_notifies executes an empty query (which is no longer necessary) and
then looks for notify responses. A practical Tcl application would have
to execute pg_notifies often, perhaps every few seconds from an "after"
timer event.
What I'd like to do is eliminate pg_notifies and define pg_listen
callbacks as happening automatically whenever Tcl can fire event
callbacks (ie, at the idle loop).
There's some risk of breaking existing applications, since the apps
might not be prepared for pg_listen callbacks occurring except at the
specific time they execute pg_notifies. But that doesn't seem really
likely to be a problem. Besides, since both these commands are
undocumented, I imagine not very many libpgtcl applications use them.
(A quick search of the archives turned up only a message from Massimo
Dal Zotto about this topic, and he seemed to agree that getting rid of
pg_notifies would be better.)
Any comments?
BTW, I'm not currently planning to tackle the other point about providing
an asynchronous pg_exec capability in libpgtcl. I've concluded that the
Tcl code I'm planning to write wouldn't use it, at least not soon; so
I'll leave that project for another person or another day.
regards, tom lane