"David G. Johnston" <david.g.johns...@gmail.com> writes:
> On Friday, December 20, 2024, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> * "Listen to all but X" seems like a reasonable desire.
> This I concur with, and would add: let me name my channels
> accounting.payables, accounting.receivables, sales.leads; and let me listen
> or ignore all accounting/sales channel names.
Hmm. That reminds me that there was recently a proposal to allow
LISTEN/UNLISTEN with pattern arguments. (It wasn't anything you'd
expect like regex patterns or LIKE patterns, but some off-the-wall
syntax, which I doubt we'd accept in that form. But clearly there's
some desire for that out there.)
While I don't say we need to implement that as part of this,
it'd be a good idea to anticipate that that will happen. And
that kind of blows a hole in my idea, because mine was predicated on
the assumption that you could unambiguously match UNLISTENs against
LISTENs. A patterned UNLISTEN might revoke a superset or subset
of previous LISTENs, and I'm not sure you could readily tell which.
I think we can still hold to the idea that LISTEN * or UNLISTEN *
cancels all previous requests, but it's feeling like we might
have to accumulate subsequent requests without trying to make
contradictory ones cancel out. Is it okay if the behavior is
explicitly dependent on the order of those requests, more or
less "last match wins"? If not, how do we avoid that?
> As for exposing this to the user, this allow-all “channel” would be
> presented as any other normal channel. The reader would need to know about
> the special meaning of whatever label we end up using. IOW, the wildcard is
> the label and no attempt to tie real in-use channel names to it should or
> even could be attempted.
Don't think that quite flies. We might have to regurgitate the
state explicitly:
LISTEN *
UNLISTEN foo.*
LISTEN foo.bar.*
showing that we're listening to channels foo.bar.*, but not other
channels beginning "foo", and also to all channels not beginning
"foo".
regards, tom lane
