From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@postgreSQL.org
To: pgsql-interfaces@postgreSQL.org
Subject: Time to fix libpgtcl for async NOTIFY
Date: Thu, 21 May 1998 19:13:35 -0400
Message-ID: <23936.895792415@sss.pgh.pa.us> (raw)
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: tgl@sss.pgh.pa.us, pgsql-hackers@postgreSQL.org
Subject: Re: Time to fix libpgtcl for async NOTIFY
In-Reply-To: <23936.895792415@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox