Hi This patch adds an ability to use patterns in *LISTEN* commands. Patch uses '*SIMILAR TO*' patterns for matching *NOTIFY* channel names ( https://www.postgresql.org/docs/9.0/static/functions-matching.html#FUNCTIONS-SIMILARTO-REGEXP ).
This patch is related to old discussion in https://www.postgresql.org/message-id/52693fc5.7070...@gmail.com. This discussion contains the reasoning behind the pattern based matching of the channel names. Patch allows the following. The listener is registered with following command, for example: *LISTEN SIMILAR TO 'test%';* which would match and receive a message from this example notfication: *NOTIFY test_2;* Unlistening the above registered pattern: *UNLISTEN 'test%';* More examples can be seen from the added regress and isolation tests. Note that *UNLISTEN* does not allow pattern based unlistening of the registered listeners. It merely matches the registered pattern by simple string comparison. This patch has no know backward compatibility issues with the existing *LISTEN*/*UNLISTEN* features. This is because patch extends the existing syntax by accepting quoted strings which define the patterns as opposed to the existing SQL literals. The patch also extends the isolationtester by adding an ability to monitor registered notify messages. This is used to test the existing features as well as the new pattern based feature. (Does not affect other existing tests) Further considerations for this patch: - Change pattern type, alternatives would be e.g. *LIKE* or POSIX patterns - Remove '*SIMILAR TO*' from the command (just use quoted string in form of *LISTEN 'test_%'*) - Allow *UNLISTEN SIMILAR TO 'xxx'* which would unregister matching listeners. To me this feels confusing therefore it is not in the patch. Some notes about patch: - Most of the changes in async.c - Regular expression is compiled and finally stored in top memory context - RE compilation (+error check) happens before transaction commit - RE is compiled in current transaction memory context from where it is copied to top memory context on transaction commit (when everything first succeeds) - Compiled REs in current transaction are freed on transaction abort - Compiled REs that were not applied as listeners (duplicates) are freed on transaction commit - REs freed when unlistened - No obvious performance impacts (e.g. normal channel name listening uses just strcmp) Thoughts? Best regards Markus
Description: Binary data
-- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers