Re: Allow LISTEN on patterns

> On Mar 3, 2025, at 10:39 PM, Quan Zongliang <quanzongliang(at)yeah(dot)net> wrote:
>
> I implemented a LISTEN command that supports matching names in the LIKE format.
>
> Just like
>
> LISTEN 'c%';
> NOTIFY c1;NOTIFY c2;
>
> Notifications are received for c1 and c2.
>
The parser down-cases ColId. Thus:

LISTEN MiXeDcAsE;
NOTIFY MIXEDCASE; — triggers notification

To which you’ve added:

LISTEN ‘MiXeDcAsE%’;

Resulting in:

NOTIFY MIXEDCASE; -- triggers original LISTEN, but not the pattern
NOTIFY ‘MiXeDcAsE’; -- triggers only the pattern LISTEN, but not the original

Perhaps you want to use ILIKE instead of LIKE?

And then we have pg_notify(), which does NOT down-case the channel name, giving:

PERFORM pg_notify(‘MiXeDcAsE’, ‘’); -- triggers only the pattern LISTEN :-(

The pg_notify() thing feels like a bug, given that historically NOTIFY takes only ColId as a parameter.

> For grammatical reasons, LISTEN 'v_'; with LISTEN v_; It's weird.
>
> Should it be defined in a way that makes it easier to distinguish?
> And support for more matching patterns.
>
> For example
> LISTEN [LIKE] 'like_pattern';
> LISTEN SIMILAR 'regex_pattern’;

Adding one of these existing key words seems preferable than to just predicating on the parsed object type.

You might have a look at [0] for fun to see what I tried recently,
— Trey

[0] https://www.postgresql.org/message-id/634685d67d0b491882169d2d0c084836%40treysoft.com