> On Dec 20, 2024, at 4:45 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> "David G. Johnston" <david.g.johnston@gmail.com> writes:
>> On Friday, December 20, 2024, Tom Lane <tgl@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.)
>
I dug into the archives prior to starting this discussion. If folks really want
this then someone should probably promote the ‘ltree’ data type from contrib
to built-in and reuse the matching code. NOTIFY, LISTEN, and UNLISTEN
all use ‘ColId’ in the grammar, limiting patterns to NAMEDATALEN, and that
probably needs to change. I didn’t propose it because it seemed like too big
of a lift for a newbie project.
> 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.
>
A version of LISTEN/UNLISTEN that accepts real patterns probably
wants a new keyword, like LISTEN_LTREE. If someone uses the new keyword
then they explicitly opt-out of non-pattern searches, perhaps?
> 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?
I’d like a solution that doesn’t require walking the entire exception list. From
your earlier email I started sketching up something based on simplehash.h,
but that doesn’t lend itself to any sort of pattern matching. I don’t think you
can go too far down the road of resolving pattern matching conflicts until
we settle on the pattern matching technique. It feels like it will devolve to
dynamically assembling some kind of unified regex tree from the various
include/exclude patterns. I’d want to do a pretty serious literature search
to see if someone has already solved the problem.
Can/Should we stick to something simpler for now?
-- Trey
