Re: Discussion on a LISTEN-ALL syntax - Mailing list pgsql-hackers
| From | David G. Johnston |
|---|---|
| Subject | Re: Discussion on a LISTEN-ALL syntax |
| Date | |
| Msg-id | CAKFQuwY+=jp2yjxWh1H+t0DDmGP0iEfxVm4mhA-Jf_3OuEtweg@mail.gmail.com Whole thread Raw |
| In response to | Re: Discussion on a LISTEN-ALL syntax (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-hackers |
On Fri, Dec 20, 2024 at 1:58 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Trey Boudreau <trey@treysoft.com> writes:
> so I'd like to propose a 'LISTEN *' equivalent to 'UNLISTEN *'.
Seems reasonable in the abstract, and given the UNLISTEN * precedent
it's hard to quibble with that syntax choice. I think what actually
needs discussing are the semantics, specifically how this'd interact
with other LISTEN/UNLISTEN actions. Explain what you think should
be the behavior after:
Answers premised on the framing explained below:
LISTEN foo;
LISTEN *;
UNLISTEN *;
-- are we still listening on foo?
Yes; the channels are orthogonal and thus order doesn't matter.
LISTEN *;
LISTEN foo;
UNLISTEN *;
-- how about now?
Yes
LISTEN *;
UNLISTEN foo;
-- how about now?
The unlisten was a no-op since listen foo was not issued; * receives everything, always.
LISTEN *;
LISTEN foo;
UNLISTEN foo;
-- does that make a difference?
If any notify foo happened in between listen foo and unlisten foo the session would receive the notify message twice - once implicitly via * and once explicitly via foo.
Alternatively, the server could see that "foo" is subscribed too for PID listener, send the message and then skip over looking for a * subscription for PID listener. Basically document that we won't send duplicates if both listen * and listen foo are present.
I don't have any strong preferences about this, but we ought to
have a clear idea of the behavior we want before we start coding.
I'm inclined to make this clearly distinct from the semantics of listen/notify. Both in command form, what is affected, and the message.
Something like:
MONITOR NOTIFICATION QUEUE;
UNMONITOR NOTIFICATION QUEUE;
Asynchronous notification "foo" [with payload ...] sent by server process with PID nnn.
If you also LISTEN foo you would also receive:
Asynchronous notification "foo" [with payload ...] received from server process with PID nnn.
Unlisten undoes Listen
Unmonitor undoes Monitor
Upon session disconnect both Unlisten * and Unmonitor are executed.
If we must shoehorn this into the existing syntax and messages I'd still want to say that * is simply a special channel name that the system recognizes and sends all notify messages to. There is no way to limit which messages get sent to you via unlisten and if you also listen to the channel foo explicitly you end up receiving multiple messages. (Alternatively, send it just to foo and have the server not look for a * listen for that specific session.)
Adding a "do not send" listing (or option) to the implementation doesn't seem beneficial enough to deal with, and would be the only way: Listen *; Unlisten foo; would be capable of not having foo messages sent to the * subscribing client. In short, a "deny (do not send) all" base posture and then permit-only policies built on top of it. Listen * is the permit-all policy.
David J.
pgsql-hackers by date: