> 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. 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
