On Mon Jun 8, 2026 at 7:16 PM -03, Tom Lane wrote:
> "Matheus Alcantara" <matheusssilv97@gmail.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.
>
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
