Re: [PATCH] TODO “Allow LISTEN on patterns”

Hi Emanuel,

I did a test over the "UNLISTEN >" behavior, and I'm not sure if this is
> expected.
> This command I assume should free all the listening channels, however, it
> doesn't
> seem to do so:

TODO “Allow LISTEN on patterns” [1] is a bit vague about that feature. So I
didn't implement it in the first version of the patch. Also I see that I
made a mistake in the documentation and mentioned that it is actually
supported. Sorry for the confusion.

Besides obvious reasons I think that your finding is especially attractive
for the following reason. We have an UNLISTEN * command. If we replace >
with * in the patch (which I actually did in the new version of the patch)
then we have a generalisation of the above command. For example, UNLISTEN
a* cancels registration on all channels which start with a.

I attached to the email the new version of the patch which supports the
requested feature. Instead of > I use * for the reason which I mentioned
above. Also I added test cases, changed documentation, etc.

I appreciate your work, Emanuel! If you have any further findings I will be
glad to adjust the patch accordingly.

[1] https://www.postgresql.org/message-id/flat/52693FC5.7070507%40gmail.com

Regards,
Alexander Cheshev

Regards,
Alexander Cheshev

On Tue, 9 Jul 2024 at 11:01, Emanuel Calvo <3manuek(at)gmail(dot)com> wrote:

>
> Hello there,
>
>
> El vie, 15 mar 2024 a las 9:01, Alexander Cheshev (<alex(dot)cheshev(at)gmail(dot)com>)
> escribió:
>
>> Hello Hackers,
>>
>> I have implemented TODO “Allow LISTEN on patterns” [1] and attached
>> the patch to the email. The patch basically consists of the following
>> two parts.
>>
>> 1. Support wildcards in LISTEN command
>>
>> Notification channels can be composed of multiple levels in the form
>> ‘a.b.c’ where ‘a’, ‘b’ and ‘c’ are identifiers.
>>
>> Listen channels can be composed of multiple levels in the form ‘a.b.c’
>> where ‘a’, ‘b’ and ‘c’ are identifiers which can contain the following
>> wildcards:
>> * ‘%’ matches everything until the end of a level. Can only appear
>> at the end of a level. For example, the notification channels ‘a.b.c’,
>> ‘a.bc.c’ match against the listen channel ‘a.b%.c’.
>> * ‘>’ matches everything to the right. Can only appear at the end of
>> the last level. For example, the notification channels ‘a.b’, ‘a.bc.d’
>> match against the listen channel ‘a.b>’.
>>
>>
> I did a test over the "UNLISTEN >" behavior, and I'm not sure if this is
> expected.
> This command I assume should free all the listening channels, however, it
> doesn't
> seem to do so:
>
> postgres=# LISTEN device1.alerts.%;
> LISTEN
> postgres=# ;
> Asynchronous notification "device1.alerts.temp" with payload "80" received
> from server process with PID 237.
> postgres=# UNLISTEN >;
> UNLISTEN
> postgres=# ; -- Here I send a notification over the same channel
> Asynchronous notification "device1.alerts.temp" with payload "80" received
> from server process with PID 237.
>
> The same happens with "UNLISTEN %;", although I'm not sure if this should
> have
> the same behavior.
>
> It stops listening correctly if I do explicit UNLISTEN (exact channel
> matching).
>
> I'll be glad to conduct more tests or checks on this.
>
> Cheers,
>
>
> --
> --
> Emanuel Calvo
> Database Engineering
> https://tr3s.ma/aobut
>
>