Re: Discussion on a LISTEN-ALL syntax

On Fri, Dec 20, 2024 at 1:58 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Trey Boudreau <trey(at)treysoft(dot)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.