Hello there,
El vie, 15 mar 2024 a las 9:01, Alexander Cheshev (<alex.ches...@gmail.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
