Thanks for the good feedback.
Good point on the pg_listening_channels(). Do you think we could change the
interface of the function? At least PG v10 has changed functions elsewhere
quite dramatically eg. related to xlog functions.
We could change the pg_listening_channels() return type
On Sun, Aug 20, 2017 at 9:56 PM, Markus Sintonen
> I also encountered this when I built it with different configuration. I
> attached updated patch with the correct number of arguments to
> 'similar_escape'. I also added preliminary documentation to
I also encountered this when I built it with different configuration. I
attached updated patch with the correct number of arguments to
'similar_escape'. I also added preliminary documentation to the patch.
(Unfortunately unable to currently compile the documentation for testing
purpose on Windows
On Tue, Aug 1, 2017 at 8:13 AM, Markus Sintonen
> This patch adds an ability to use patterns in LISTEN commands. Patch uses
> 'SIMILAR TO' patterns for matching NOTIFY channel names
The following does not work:
LISTEN SIMILAR TO "foo%"
But it does not act as a pattern.
We could change the SIMILAR TO something like following (accepting also
type of the pattern), for example:
LISTEN PATTERN 'foo%' TYPE 'similar'
On 7/31/17 16:13, Markus Sintonen wrote:
> 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.
This patch adds an ability to use patterns in *LISTEN* commands. Patch uses
'*SIMILAR TO*' patterns for matching *NOTIFY* channel names (
This patch is related to old discussion in