-- notification NOT delivered
PERFORM pg_notify(‘foo’, ‘BAR’); -- notification delivered
Can we come to some agreement on if we should consider this a bug?
— Trey
ttern';
> LISTEN SIMILAR 'regex_pattern’;
Adding one of these existing key words seems preferable than to just
predicating on the parsed object type.
You might have a look at [0] for fun to see what I tried recently,
— Trey
[0]
https://www.postgresql.org/message-id/634685d67d0b491882169d2d0c084836%40treysoft.com
pg_listening_channels()provides no clue that, after 'LISTEN *', the results list exceptionsrather than notifiable channels.[1]: https://www.postgresql.org/message-id/737106.1734732462%40sss.pgh.pa.us-- Trey
v1-0001-Make-simplehash-more-flexible.patch
Description: Binary data
v1-0002-Improve-LIS
On 2024-12-24 13:09, Trey Boudreau wrote:
Based on [1], please find attached an implementation for listening
for notifications on all channels. The first two chunks lay some
groundwork and do not change the current LISTEN behavior, except
to improve performance of managing large numbers of
e-parsed regex from the exception list by encapsulating
the patterns in something like ‘(^’‘$)’ and aggregating with ‘|’.
We could alternatively have ‘pg_listen_pattern(style)’, with style
choices of IDENT (current behavior), REGEX, LTREE, LIKE, etc.
So long as we treated all of the exceptions as the same type it seems
pretty sane. Allowing mixing would take lots of work.
-- Trey
kind of unified regex tree from the various
include/exclude patterns. I’d want to do a pretty serious literature search
to see if someone has already solved the problem.
Can/Should we stick to something simpler for now?
-- Trey
NLISTEN *’
feels extremely impolite, and if we leave that alone I don’t see using
the ‘LISTEN *’ syntax with behavior that leaves other LISTENs in place.
We could have a different set of keywords, like LISTEN_ALL/UNLISTEN_ALL
that doesn’t interfere with the existing behavior.
-- Trey
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
