On 2025/3/4 23:57, Trey Boudreau wrote:
On Mar 3, 2025, at 10:39 PM, Quan Zongliang <quanzongli...@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.
Yes, my considerations are superficial and need to be revisited.
I have replied in Tom's email.
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 <https://
www.postgresql.org/message-
id/634685d67d0b491882169d2d0c084836%40treysoft.com>
Very good patch. Could you also consider adding "LISTEN ALL" and
"UNLISTEN ALL"?
Users may feel more convenient and clear.
