Discussion on a LISTEN-ALL syntax

From: Trey Boudreau <trey(at)treysoft(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Discussion on a LISTEN-ALL syntax
Date: 2024-12-20 18:56:20
Message-ID: A14CC639-E89D-4367-894D-883DBEC503B1@treysoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Howdy all,

NOTE: Grey-beard coder, pgsql newbie. All info/tips/suggestions welcome!

I have a use-case where I’d like to LISTEN for all NOTIFY channels. Right now I simply
issue a LISTEN for every channel name of interest, but in production the channels will
number in the low thousands. The current implementation uses a linked list, and a linear
probe through the list of desired channels which will always return true becomes quite
expensive at this scale.

I have a work-around available by creating the “ALL” channel and making the payload
include the actual channel name, but this has a few of drawbacks:
* it does not play nice with clients that actually want a small subset of channels;
* it requires code modification at every NOTIFY;
* it requires extra code on the client side.

The work-around subjects the developer (me :-) to significant risk of foot-gun disease,
so I'd like to propose a 'LISTEN *' equivalent to 'UNLISTEN *'.

The implementation in src/backend/commands/async.c seems straightforward enough, but it
feels prudent to select a syntax that doesn't make some kind of actual pattern matching
syntactically ugly in the future. Choosing 'LISTEN *' has a nice symmetry with 'UNLISTEN
*', but I don't have enough SQL chops to know if it cause problems.

If anyone has a better work-around, please speak up! If not, and we can come to some
resolution on a future-resistant syntax, I'd happily start working up a patch set.

Thanks,
-- Trey Boudreau

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2024-12-20 19:16:52 Re: Fix crash when non-creator being an iteration on shared radix tree
Previous Message Andres Freund 2024-12-20 17:39:33 Re: AIO v2.0