| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> |
| Cc: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Add pattern matching support for LISTEN/NOTIFY channels |
| Date: | 2026-06-08 22:16:46 |
| Message-ID: | 617411.1780957006@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Matheus Alcantara" <matheusssilv97(at)gmail(dot)com> writes:
> I'd like to propose for PG 20 adding glob-style pattern matching support
> for LISTEN channel names, allowing clients to subscribe to multiple
> channels with a single LISTEN command using wildcards.
I'm fairly skeptical that this is worth supporting at the server-code
level. You can already accomplish equivalent things by listening on
a single shared channel and pattern-matching against identifiers
provided in the message payloads. Yes, doing that in C would reduce
the cost of skipping uninteresting messages, but is that enough of a
gain to justify adding this to our support workload?
The proposed implementation doesn't seem that attractive anyway, since
it gives up all the benefit of the targeted wakeups introduced in v19.
If you consider a workload with some high-volume channels that are not
interesting to the wild-card-using listener, it's not hard to believe
that this is a net loss compared to the already-usable way.
(Hmm, I wonder if the feature ought to look like "match a pattern
to the message body" rather than matching to the channel name,
ie push the already-usable filtering design down to the C level.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Matheus Alcantara | 2026-06-08 23:08:46 | Re: Add pattern matching support for LISTEN/NOTIFY channels |
| Previous Message | Jeff Davis | 2026-06-08 21:55:19 | Re: Avoid orphaned objects dependencies, take 3 |