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

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