Re: Define jsonpath functions as stable - Mailing list pgsql-hackers

From Jonathan S. Katz
Subject Re: Define jsonpath functions as stable
Date
Msg-id e0c9f09b-d449-6eba-af84-3f27bd5e47cf@postgresql.org
Whole thread Raw
In response to Re: Define jsonpath functions as stable  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Define jsonpath functions as stable
List pgsql-hackers
On 9/19/19 3:48 PM, Tom Lane wrote:
> "Jonathan S. Katz" <jkatz@postgresql.org> writes:
>> I looked at the patch, but did not test it. From what I can see, it
>> looks good, but perhaps we add a test in it to show that single-quoted
>> literals are unsupported?
>
> I thought about that, but it seems like it'd be memorializing some
> other weird behavior:
>
> regression=# select '''foo'''::jsonpath;
> ERROR:  syntax error, unexpected IDENT_P at end of jsonpath input
> LINE 1: select '''foo'''::jsonpath;
>                ^
>
> regression=# select '''foo'' <= ''bar'''::jsonpath;
> ERROR:  syntax error, unexpected IDENT_P at or near " " of jsonpath input
> LINE 1: select '''foo'' <= ''bar'''::jsonpath;
>                ^

Ah yeah, those are some interesting errors.

> There isn't anything I like about these error messages.

Agreed. It would be nice to have tests around it, but yes, I think
looking at the regression outpout one may scratch their head.

>  Seems like
> the error handling in jsonpath_gram.y could use some cleanup too
> ... although I don't think it's a task to tackle while we're
> rushing to get v12 shippable.

IIRC if we want to change the contents of an error message we wait until
major releases. Is there anything we can do before 12 to avoid messages
like "unexpected IDENT_P" coming to a user? Would that be something
acceptable to fix as a 12.1 or would it have to wait until 13?

Jonathan


Attachment

pgsql-hackers by date:

Previous
From: Nikita Glukhov
Date:
Subject: Re: Bug in GiST paring heap comparator
Next
From: Tom Lane
Date:
Subject: Re: Define jsonpath functions as stable