Re: Allow LISTEN on patterns

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.