| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Trey Boudreau <trey(at)treysoft(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, Quan Zongliang <quanzongliang(at)yeah(dot)net> |
| Subject: | Re: Allow LISTEN on patterns |
| Date: | 2025-03-05 17:25:58 |
| Message-ID: | 321080.1741195558@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Trey Boudreau <trey(at)treysoft(dot)com> writes:
> I didn’t see any past references to the pg_notify() ‘anomaly’:
> LISTEN FOO;
> NOTIFY FOO, ‘BAR’; -- notification delivered
> PERFORM pg_notify(‘FOO’, ‘BAR’); -- notification NOT delivered
> PERFORM pg_notify(‘foo’, ‘BAR’); -- notification delivered
> Can we come to some agreement on if we should consider this a bug?
I don't think it's a bug particularly. The actual channel name
being listened to is lowercase "foo", per the usual SQL identifier
case-folding rules. But pg_notify is taking a literal not an
identifier, so you have to match case.
We do have some functions that downcase the input string unless
double-quoted, so that the experience is closer to what you get
for a SQL identifier. Perhaps pg_notify should have done that
for the channel name, but it didn't and I think it's much too late
to revisit that.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Bertrand Drouvot | 2025-03-05 17:26:40 | Re: per backend WAL statistics |
| Previous Message | Daniel Gustafsson | 2025-03-05 17:21:40 | Re: Adding support for SSLKEYLOGFILE in the frontend |