Time to fix libpgtcl for async NOTIFY
От | Tom Lane |
---|---|
Тема | Time to fix libpgtcl for async NOTIFY |
Дата | |
Msg-id | 23936.895792415@sss.pgh.pa.us обсуждение исходный текст |
Ответы |
Re: [HACKERS] Time to fix libpgtcl for async NOTIFY
|
Список | pgsql-interfaces |
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
В списке pgsql-interfaces по дате отправления: