Re: Allow LISTEN on patterns - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allow LISTEN on patterns
Date
Msg-id 316388.1741192968@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allow LISTEN on patterns  (Aleksander Alekseev <aleksander@timescale.com>)
Responses Re: Allow LISTEN on patterns
Re: Allow LISTEN on patterns
List pgsql-hackers
Aleksander Alekseev <aleksander@timescale.com> writes:
> For instance, if I do:

> ```
> LISTEN aaafoo;
> LISTEN aaabar;
> UNLISTEN aaa%;
> ```

> Should I:

> A. be unsubscribed from aaafoo and aaabar since both match aaa% or
> B. UNLISTEN should have no effect since I never subscribed to aaa% explicitly?

Yeah, the whole question of how LISTEN and UNLISTEN should interact
was one of the stumbling blocks that previous proposals in this
line ([1][2][3], and I think there were more) couldn't get past.
Another interesting variant is

    LISTEN 'foo%';
    UNLISTEN 'foobar%';

Does this leave you listening to foobazbar but not foobarbaz?
That seems like it'd be what the user expects, but how can we
implement that efficiently?  It seems like a series of N such
commands could leave us in a state where we have to do N
pattern-matches to decide if a channel name is being listened
to, which seems annoyingly expensive.

Also consider the reverse case:

    LISTEN 'foobar%';
    UNLISTEN 'foo%';

ISTM that this should leave you listening to nothing, but can
we practically detect that, or are we going to end up doing
two useless pattern matches for every incoming message?
What this comes down to is whether we can recognize that one
pattern is a superset of another.  That feels like it might
be possible for simple LIKE patterns, but almost certainly
not for regexes.

Anyway, I encourage reading some of the past threads on this
topic.

            regards, tom lane

[1] https://www.postgresql.org/message-id/flat/A14CC639-E89D-4367-894D-883DBEC503B1%40treysoft.com
[2] https://www.postgresql.org/message-id/flat/CAN_hQmuysJpMzWcyhQwYtHpao8XXMpc48A8F%3Dn-0e6x_z2P_Fw%40mail.gmail.com
[3] https://www.postgresql.org/message-id/flat/CAMpj9JbqhgQ5HjydoP0fovewQdOcu2c4RF5KKkH6J6ZNUjb2Rg%40mail.gmail.com



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: log_min_messages per backend type
Next
From: Mahendra Singh Thalor
Date:
Subject: Re: Non-text mode for pg_dumpall