> On Dec 20, 2024, at 2:58 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.
My first pass at the documentation looks like this:
<para>
The special wildcard <literal>*</literal> cancels all listener
registrations for the current session and replaces them with a
virtual registration that matches all channels. Further
<command>LISTEN</command> and <command>UNLISTEN <replaceable
class="parameter">channel</replaceable></command> commands will
be ignored until the session sees the <command>UNLISTEN *</command>
command.
</para>
> Explain what you think should
> be the behavior after:
>
> LISTEN foo;
> LISTEN *;
> UNLISTEN *;
> -- are we still listening on foo?
>
No, as the ‘LISTEN *’ wipes existing registrations.
> LISTEN *;
> LISTEN foo;
> UNLISTEN *;
> -- how about now?
Not listening on ‘foo’ or anything else.
> LISTEN *;
> UNLISTEN foo;
> -- how about now?
‘UNLISTEN foo’ ignored.
> LISTEN *;
> LISTEN foo;
> UNLISTEN foo;
> -- does that make a difference?
‘LISTEN foo’ and ‘UNLISTEN foo’ ignored, leaving only the wildcard.
> 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.
These semantics made sense to me, but I have limited experience and
a very specific use case in mind. Changing the behavior of ‘UNLISTEN *’
feels extremely impolite, and if we leave that alone I don’t see using
the ‘LISTEN *’ syntax with behavior that leaves other LISTENs in place.
We could have a different set of keywords, like LISTEN_ALL/UNLISTEN_ALL
that doesn’t interfere with the existing behavior.
-- Trey
