Massimo Dal Zotto <dz@cs.unitn.it> writes:
> If you are making changes to the tcl listen code please consider adding the
> following missing feature:
> - the possibility to temporarily suspend callbacks for a particular listen
> or for all listens. This would help to avoid the above possible problem.
That seems reasonable. I presume that if a notify comes in while the
callback is suspended, we should fire the callback after it gets
reenabled? What happens if multiple notifies for the same name arrive
while suspended --- one callback afterwards, or many? (I think I'd vote
for only one, but...)
> - an option to get the callback associated to a particular listen or to all
> listens
Perhaps also reasonable. In the code I submitted last night, it is
possible for several different Tcl interpreters to be listening within
one client process. I think that an interpreter should only be able to
ask about its own callbacks, however --- anything else is a security
violation that defeats the point of multiple interpreters.
(Your "suspend callbacks" feature would likewise have to be interpreter-
local.)
> - better support for unlistening. There is an unlisten function in my
> contrib code but it should be integrated into the backend with a real
> UNLISTEN command.
I agree with that, and will do the libpq and libpgtcl changes if someone
else will implement UNLISTEN on the backend side. I'm not competent to
twiddle the backend however.
regards, tom lane
PS: I'm on vacation till next week. Don't expect any fast responses.