On Dec 20, 2024, at 4:07 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Hmph. After thinking about it a bit I have a different idea
(and I see David has yet a third one). So maybe this is more
contentious than it seems. But at any rate, I have two
fundamental thoughts:
* "Listen to all but X" seems like a reasonable desire.
* The existing implementation already has the principle that
you can't listen to a channel more than once; that is,
LISTEN foo;
LISTEN foo; -- this is a no-op, not a duplicate subscription
Therefore I propose:
* "LISTEN *" wipes away all previous listen state, and
sets up a state where you're listening to all channels
(within your database).
* "UNLISTEN *" wipes away all previous listen state, and
sets up a state where you're listening to no channels
(which is the same as it does now).
* "LISTEN foo" adds "foo" to what you are listening to,
with no effect if you already were listening to foo
(whether it was a virtual or explicit listen).
* "UNLISTEN foo" removes "foo" from what you are listening to,
with no effect if you already weren't listening to foo.
I have an implementation of this that replaces List with a simplehash.h
variant, merging 'plus/minus' as ‘exceptions’.
One other thing that needs to be thought about in any case
is what the pg_listening_channels() function ought to return
in these newly-possible states.
My previous cut at this replaced the list with ‘*’, but since we now
allow exceptions, how about preceding the list with ‘*” in the
Want-all case, following with the list of exceptions?
In another branch of this discussion covering patterns I mentioned
building a tree of regular expressions. If we go with the notion of
‘want-all/want-none, with exceptions’ then we could introduce a
function like ‘pg_listens_use_regexes(bool)’. When true we’d
build a pre-parsed regex from the exception list by encapsulating
the patterns in something like ‘(^’<pattern>‘$)’ and aggregating with ‘|’.
We could alternatively have ‘pg_listen_pattern(style)’, with style
choices of IDENT (current behavior), REGEX, LTREE, LIKE, etc.
So long as we treated all of the exceptions as the same type it seems
pretty sane. Allowing mixing would take lots of work.
-- Trey
