On Mar 3, 2025, at 10:39 PM, Quan Zongliang <quanzongliang@yeah.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
