Fwd: [PATCH] Pattern based listeners for asynchronous messaging (LISTEN/NOTIFY)

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 probably because of commit https://github.com/
postgres/postgres/commit/510074f9f0131a04322d6a3d2a51c87e6db243f9. I
followed https://www.postgresql.org/docs/devel/static/install-
windows-full.html#idm45412738673840.)

What do you think about the syntax? There was a suggestion to specify type
of the pattern (eg ltree extension) but to me this feels like a overkill.
One option here would be eg:
LISTEN PATTERN 'foo%' TYPE 'similar'
LISTEN PATTERN 'foo.*' TYPE 'ltree'
... and so on

BR
-Markus

2017-08-19 2:36 GMT+03:00 Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>:

> On Tue, Aug 1, 2017 at 8:13 AM, Markus Sintonen
> <markus(dot)sintonen(at)gmail(dot)com> wrote:
> > 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-matchi
> ng.html#FUNCTIONS-SIMILARTO-REGEXP).
> >
> > This patch is related to old discussion in
> > https://www.postgresql.org/message-id/52693FC5.7070507@gmail.com. This
> > discussion contains the reasoning behind the pattern based matching of
> the
> > channel names.
>
> Nice idea.
>
> The "async" regression test consistently crashes on my FreeBSD box
> when built with -O2. It doesn't crash on another system I tried, and
> I think that's just luck, because this:
>
> + /* convert to regex pattern */
> + datum = DirectFunctionCall1(similar_escape,
> CStringGetTextDatum(pattern));
>
> ... is calling a function that takes two arguments, but passing only
> one. The second argument is random junk, so similar_escape bombs when
> it does this:
>
> esc_text = PG_GETARG_TEXT_PP(1);
>
> --
> Thomas Munro
> http://www.enterprisedb.com
>