Discussion on a LISTEN-ALL syntax - Mailing list pgsql-hackers

From Trey Boudreau
Subject Discussion on a LISTEN-ALL syntax
Date
Msg-id A14CC639-E89D-4367-894D-883DBEC503B1@treysoft.com
Whole thread Raw
Responses Re: Discussion on a LISTEN-ALL syntax
List 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




pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: AIO v2.0
Next
From: Masahiko Sawada
Date:
Subject: Re: Fix crash when non-creator being an iteration on shared radix tree