Re: Add pattern matching support for LISTEN/NOTIFY channels

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

In response to

Responses

Browse pgsql-hackers by date

  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