Re: Add pattern matching support for LISTEN/NOTIFY channels

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

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