On 2025/3/4 23:57, Trey Boudreau wrote:
>
>> 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.
>
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.
