Thread: JSON/SQL: jsonpath: incomprehensible error message
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
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
Attachment
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.
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
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
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
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.
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