On Mon Jun 8, 2026 at 7:16 PM -03, Tom Lane wrote: > "Matheus Alcantara" <[email protected]> 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. >
Yeah, I agree with this. I'm currently looking for other possibilities. > (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.) > It seems like an interesting direction, I'm wondering if something like this would make sense? LISTEN events WHERE payload LIKE 'user_%'; -- Pattern match Or LISTEN events WHERE payload = 'something'; -- Exclusive match -- Matheus Alcantara EDB: https://www.enterprisedb.com
