On 2022-06-29 We 10:58, Alexander Korotkov wrote:
> On Wed, Jun 29, 2022 at 4:28 PM Erik Rijkers <e...@xs4all.nl> wrote:
>> Op 29-06-2022 om 15:00 schreef Amit Kapila:
>>> On Mon, Jun 27, 2022 at 8:46 PM Andrew Dunstan <and...@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
