Horton

Thread

Commits

  1. Remove %error-verbose directive from jsonpath parser

  2. Partial implementation of SQL/JSON path language

  1. JSON/SQL: jsonpath: incomprehensible error message

    Erik Rijkers <er@xs4all.nl> — 2022-06-26T15:44:22Z

    JSON/SQL jsonpath

For example, a jsonpath string with deliberate typo 'like_regexp' 
(instead of 'like_regex'):

select js
from (values (jsonb '{}')) as f(js)
where js @? '$ ? (@ like_regexp "^xxx")';

ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input
LINE 1: ...s from (values (jsonb '{}')) as f(js) where js @? '$ ? (@ li...
                                                              ^

Both  'IDENT_P'  and  'at or near " "'  seem pretty useless.

Perhaps some improvement can be thought of?

Similar messages in release 14 seem to use 'invalid token', which is better:

select js
from (values (jsonb '{"a":"b"}')) as f(js)
where js @? '$ ? (@.a .= "b")';
ERROR:  syntax error, unexpected invalid token at or near "=" of 
jsonpath input

thanks,
Erik Rijkers

  2. Re: JSON/SQL: jsonpath: incomprehensible error message

    Andrew Dunstan <andrew@dunslane.net> — 2022-06-27T15:15:57Z

    On 2022-06-26 Su 11:44, Erik Rijkers wrote:
> JSON/SQL jsonpath
>
> For example, a jsonpath string with deliberate typo 'like_regexp'
> (instead of 'like_regex'):
>
> select js
> from (values (jsonb '{}')) as f(js)
> where js @? '$ ? (@ like_regexp "^xxx")';
>
> ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input
> LINE 1: ...s from (values (jsonb '{}')) as f(js) where js @? '$ ? (@
> li...
>                                                              ^
>
> Both  'IDENT_P'  and  'at or near " "'  seem pretty useless.
>
> Perhaps some improvement can be thought of?
>
> Similar messages in release 14 seem to use 'invalid token', which is
> better:
>
> select js
> from (values (jsonb '{"a":"b"}')) as f(js)
> where js @? '$ ? (@.a .= "b")';
> ERROR:  syntax error, unexpected invalid token at or near "=" of
> jsonpath input
>
>

Yeah :-(

This apparently goes back to the original jsonpath commit 72b6460336e.
There are similar error messages in the back branch regression tests:

andrew@ub20:pgl $ grep -r IDENT_P pg_*/src/test/regress/expected/
pg_12/src/test/regress/expected/jsonpath.out:ERROR:  syntax error, unexpected IDENT_P at end of jsonpath input
pg_13/src/test/regress/expected/jsonpath.out:ERROR:  syntax error, unexpected IDENT_P at end of jsonpath input
pg_14/src/test/regress/expected/jsonpath.out:ERROR:  syntax error, unexpected IDENT_P at end of jsonpath input

For some reason the parser contains a '%error-verbose' directive, unlike
all our other bison parsers. Removing that fixes it, as in this patch.
I'm a bit inclined to say we should backpatch the removal of the
directive, but I guess a lack of complaints suggests it's not a huge issue.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

  3. Re: JSON/SQL: jsonpath: incomprehensible error message

    Amit Kapila <amit.kapila16@gmail.com> — 2022-06-29T13:00:50Z

    On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan <andrew@dunslane.net> wrote:
>
> On 2022-06-26 Su 11:44, Erik Rijkers wrote:
> > JSON/SQL jsonpath
> >
> > For example, a jsonpath string with deliberate typo 'like_regexp'
> > (instead of 'like_regex'):
> >
> > select js
> > from (values (jsonb '{}')) as f(js)
> > where js @? '$ ? (@ like_regexp "^xxx")';
> >
> > ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input
> > LINE 1: ...s from (values (jsonb '{}')) as f(js) where js @? '$ ? (@
> > li...
> >                                                              ^
> >
> > Both  'IDENT_P'  and  'at or near " "'  seem pretty useless.
> >
> > Perhaps some improvement can be thought of?
> >
> > Similar messages in release 14 seem to use 'invalid token', which is
> > better:
> >
> > select js
> > from (values (jsonb '{"a":"b"}')) as f(js)
> > where js @? '$ ? (@.a .= "b")';
> > ERROR:  syntax error, unexpected invalid token at or near "=" of
> > jsonpath input
> >
> >
>
> Yeah :-(
>
> This apparently goes back to the original jsonpath commit 72b6460336e.
> There are similar error messages in the back branch regression tests:
>
> andrew@ub20:pgl $ grep -r IDENT_P pg_*/src/test/regress/expected/
> pg_12/src/test/regress/expected/jsonpath.out:ERROR:  syntax error, unexpected IDENT_P at end of jsonpath input
> pg_13/src/test/regress/expected/jsonpath.out:ERROR:  syntax error, unexpected IDENT_P at end of jsonpath input
> pg_14/src/test/regress/expected/jsonpath.out:ERROR:  syntax error, unexpected IDENT_P at end of jsonpath input
>
> For some reason the parser contains a '%error-verbose' directive, unlike
> all our other bison parsers. Removing that fixes it, as in this patch.
> I'm a bit inclined to say we should backpatch the removal of the
> directive,
>

I guess it is okay to backpatch unless we think some user will be
dependent on such a message or there could be other side effects of
removing this. One thing that is not clear to me is why OP sees an
acceptable message (ERROR:  syntax error, unexpected invalid token at
or near "=" of jsonpath input) for a similar query in 14?

-- 
With Regards,
Amit Kapila.

  4. Re: JSON/SQL: jsonpath: incomprehensible error message

    Erik Rijkers <er@xs4all.nl> — 2022-06-29T13:28:02Z

    Op 29-06-2022 om 15:00 schreef Amit Kapila:
> On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan <andrew@dunslane.net> wrote:
>>
>> On 2022-06-26 Su 11:44, Erik Rijkers wrote:
>>> JSON/SQL jsonpath
>>>
>>> For example, a jsonpath string with deliberate typo 'like_regexp'
>>> (instead of 'like_regex'):
>>>
>>> select js
>>> from (values (jsonb '{}')) as f(js)
>>> where js @? '$ ? (@ like_regexp "^xxx")';
>>>
>>> ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input
>>> LINE 1: ...s from (values (jsonb '{}')) as f(js) where js @? '$ ? (@
>>> li...
>>>
>>> Both  'IDENT_P'  and  'at or near " "'  seem pretty useless.
>>>

> removing this. One thing that is not clear to me is why OP sees an
> acceptable message (ERROR:  syntax error, unexpected invalid token at
> or near "=" of jsonpath input) for a similar query in 14?

To mention that was perhaps unwise of me because The  IDENT_P (or more 
generally, *_P)  messages can be provoked on 14 too. I just thought 
'invalid token' might be a better message because 'token' gives a more 
direct association with 'errors during parsing' which I assume is the 
case here.

IDENT_P or ANY_P convey exactly nothing.


Erik

  5. Re: JSON/SQL: jsonpath: incomprehensible error message

    Alexander Korotkov <aekorotkov@gmail.com> — 2022-06-29T14:58:37Z

    On Wed, Jun 29, 2022 at 4:28 PM Erik Rijkers <er@xs4all.nl> wrote:
> Op 29-06-2022 om 15:00 schreef Amit Kapila:
> > On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan <andrew@dunslane.net> wrote:
> >>
> >> On 2022-06-26 Su 11:44, Erik Rijkers wrote:
> >>> JSON/SQL jsonpath
> >>>
> >>> For example, a jsonpath string with deliberate typo 'like_regexp'
> >>> (instead of 'like_regex'):
> >>>
> >>> select js
> >>> from (values (jsonb '{}')) as f(js)
> >>> where js @? '$ ? (@ like_regexp "^xxx")';
> >>>
> >>> ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input
> >>> LINE 1: ...s from (values (jsonb '{}')) as f(js) where js @? '$ ? (@
> >>> li...
> >>>
> >>> Both  'IDENT_P'  and  'at or near " "'  seem pretty useless.
> >>>
>
> > removing this. One thing that is not clear to me is why OP sees an
> > acceptable message (ERROR:  syntax error, unexpected invalid token at
> > or near "=" of jsonpath input) for a similar query in 14?
>
> To mention that was perhaps unwise of me because The  IDENT_P (or more
> generally, *_P)  messages can be provoked on 14 too. I just thought
> 'invalid token' might be a better message because 'token' gives a more
> direct association with 'errors during parsing' which I assume is the
> case here.
>
> IDENT_P or ANY_P convey exactly nothing.

+1

------
Regards,
Alexander Korotkov

  6. Re: JSON/SQL: jsonpath: incomprehensible error message

    Andrew Dunstan <andrew@dunslane.net> — 2022-06-29T15:29:45Z

    On 2022-06-29 We 10:58, Alexander Korotkov wrote:
> On Wed, Jun 29, 2022 at 4:28 PM Erik Rijkers <er@xs4all.nl> wrote:
>> Op 29-06-2022 om 15:00 schreef Amit Kapila:
>>> On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan <andrew@dunslane.net> wrote:
>>>> On 2022-06-26 Su 11:44, Erik Rijkers wrote:
>>>>> JSON/SQL jsonpath
>>>>>
>>>>> For example, a jsonpath string with deliberate typo 'like_regexp'
>>>>> (instead of 'like_regex'):
>>>>>
>>>>> select js
>>>>> from (values (jsonb '{}')) as f(js)
>>>>> where js @? '$ ? (@ like_regexp "^xxx")';
>>>>>
>>>>> ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input
>>>>> LINE 1: ...s from (values (jsonb '{}')) as f(js) where js @? '$ ? (@
>>>>> li...
>>>>>
>>>>> Both  'IDENT_P'  and  'at or near " "'  seem pretty useless.
>>>>>
>>> removing this. One thing that is not clear to me is why OP sees an
>>> acceptable message (ERROR:  syntax error, unexpected invalid token at
>>> or near "=" of jsonpath input) for a similar query in 14?
>> To mention that was perhaps unwise of me because The  IDENT_P (or more
>> generally, *_P)  messages can be provoked on 14 too. I just thought
>> 'invalid token' might be a better message because 'token' gives a more
>> direct association with 'errors during parsing' which I assume is the
>> case here.
>>
>> IDENT_P or ANY_P convey exactly nothing.
> +1
>


I agree, but I don't think "invalid token" is all that much better. I
think the right fix is just to get rid of the parser setting that causes
production of these additions to the error message, and make it just
like all the other bison parsers we have. Then the problem just disappears.

It's a very slight change of behaviour, but I agree with Amit that we
can backpatch it. I will do so shortly unless there's an objection.


cheers


andrew


--
Andrew Dunstan
EDB: https://www.enterprisedb.com

  7. Re: JSON/SQL: jsonpath: incomprehensible error message

    Amit Kapila <amit.kapila16@gmail.com> — 2022-06-30T08:19:53Z

    On Wed, Jun 29, 2022 at 6:58 PM Erik Rijkers <er@xs4all.nl> wrote:
>
> Op 29-06-2022 om 15:00 schreef Amit Kapila:
> > On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan <andrew@dunslane.net> wrote:
> >>
> >> On 2022-06-26 Su 11:44, Erik Rijkers wrote:
> >>> JSON/SQL jsonpath
> >>>
> >>> For example, a jsonpath string with deliberate typo 'like_regexp'
> >>> (instead of 'like_regex'):
> >>>
> >>> select js
> >>> from (values (jsonb '{}')) as f(js)
> >>> where js @? '$ ? (@ like_regexp "^xxx")';
> >>>
> >>> ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input
> >>> LINE 1: ...s from (values (jsonb '{}')) as f(js) where js @? '$ ? (@
> >>> li...
> >>>
> >>> Both  'IDENT_P'  and  'at or near " "'  seem pretty useless.
> >>>
>
> > removing this. One thing that is not clear to me is why OP sees an
> > acceptable message (ERROR:  syntax error, unexpected invalid token at
> > or near "=" of jsonpath input) for a similar query in 14?
>
> To mention that was perhaps unwise of me because The  IDENT_P (or more
> generally, *_P)  messages can be provoked on 14 too.
>

Okay, then I think it is better to backpatch this fix.

-- 
With Regards,
Amit Kapila.

  8. Re: JSON/SQL: jsonpath: incomprehensible error message

    Andrew Dunstan <andrew@dunslane.net> — 2022-07-03T21:28:34Z

    On 2022-06-30 Th 04:19, Amit Kapila wrote:
> On Wed, Jun 29, 2022 at 6:58 PM Erik Rijkers <er@xs4all.nl> wrote:
>> Op 29-06-2022 om 15:00 schreef Amit Kapila:
>>> On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan <andrew@dunslane.net> wrote:
>>>> On 2022-06-26 Su 11:44, Erik Rijkers wrote:
>>>>> JSON/SQL jsonpath
>>>>>
>>>>> For example, a jsonpath string with deliberate typo 'like_regexp'
>>>>> (instead of 'like_regex'):
>>>>>
>>>>> select js
>>>>> from (values (jsonb '{}')) as f(js)
>>>>> where js @? '$ ? (@ like_regexp "^xxx")';
>>>>>
>>>>> ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input
>>>>> LINE 1: ...s from (values (jsonb '{}')) as f(js) where js @? '$ ? (@
>>>>> li...
>>>>>
>>>>> Both  'IDENT_P'  and  'at or near " "'  seem pretty useless.
>>>>>
>>> removing this. One thing that is not clear to me is why OP sees an
>>> acceptable message (ERROR:  syntax error, unexpected invalid token at
>>> or near "=" of jsonpath input) for a similar query in 14?
>> To mention that was perhaps unwise of me because The  IDENT_P (or more
>> generally, *_P)  messages can be provoked on 14 too.
>>
> Okay, then I think it is better to backpatch this fix.



Done.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com