Re: jsonpath - Mailing list pgsql-hackers

Andrew Dunstan <andrew.dunstan@2ndquadrant.com> writes:
> I was able to get this stack trace.
>
> (gdb) bt
> #0  0x00007ffb9ce6a458 in ntdll!RtlRaiseStatus ()
>    from C:\WINDOWS\SYSTEM32\ntdll.dll
> #1  0x00007ffb9ce7760e in ntdll!memset () from C:\WINDOWS\SYSTEM32\ntdll.dll
> #2  0x00007ffb9ac52e1a in msvcrt!_setjmpex ()
>    from C:\WINDOWS\System32\msvcrt.dll
> #3  0x000000000087431a in pg_re_throw ()
>     at c:/MinGW/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.build/../pgsql/src/backend/utils/error/elog.c:1720
> #4  0x0000000000874106 in errfinish (dummy=<optimized out>)
>     at c:/MinGW/msys/1.0/home/pgrunner/bf/root/HEAD/pgsql.build/../pgsql/src/backend/utils/error/elog.c:464
> #5  0x00000000007cc938 in jsonpath_yyerror (result=result@entry=0x0,
>     message=message@entry=0xab0868 <__func__.110231+1592> "unrecognized flag of LIKE_REGEX predicate")
>     at /home/pgrunner/bf/root/HEAD/pgsql.build/../pgsql/src/backend/utils/adt/jsonpath_scan.l:305
> #6  0x00000000007cec9d in makeItemLikeRegex (pattern=<optimized out>,
>     pattern=<optimized out>, flags=<optimized out>, expr=0x73c7a80)
>     at /home/pgrunner/bf/root/HEAD/pgsql.build/../pgsql/src/backend/utils/adt/jsonpath_gram.y:512

Hmm.  Reaching the yyerror call is expected given this input, but
seemingly the siglongjmp stack has been trashed?  The best I can
think of is a wild store that either occurs only on this platform
or happens to be harmless elsewhere ... but neither idea is terribly
convincing.

BTW, the expected behavior according to the regression test is

regression=# select '$ ? (@ like_regex "pattern" flag "a"'::jsonpath;
ERROR:  bad jsonpath representation
LINE 1: select '$ ? (@ like_regex "pattern" flag "a"'::jsonpath;
               ^
DETAIL:  unrecognized flag of LIKE_REGEX predicate at or near """

which leaves quite a lot to be desired already.  The "bad whatever"
error wording is a flat out violation of our message style guide,
while the "at or near """" bit is pretty darn unhelpful.

The latter problem occurs because the last flex production was

<xq>\"                          {
                                    yylval->str = scanstring;
                                    BEGIN INITIAL;
                                    return STRING_P;
                                }

so that flex thinks the last token was just the quote mark ending the
string.  This could be improved on by adopting something similar to the
SET_YYLLOC() convention used in scan.l to remember the start of what the
user would think the token is.  Probably it's not worth the work right
now, but details like this are important from a fit-and-finish
perspective, so I'd like to see it improved sometime.

            regards, tom lane