Re: Define jsonpath functions as stable

On 9/19/19 12:25 PM, Tom Lane wrote:
> I wrote:
>> I found a spot that seemed like a reasonable place, and added some
>> coverage of the point.  Updated patch attached.
> 
> Doc patch pushed.

Thanks! I did not get to review them last night but upon review not too
long ago, they looked great.

>> It seems to me that there are some discrepancies between what the spec
>> says and what jsonpath_scan.l actually does, so maybe we should take a
>> hard look at that code too.  The biggest issue is that jsonpath_scan.l
>> seems to allow single- and double-quoted strings interchangeably, which is
>> OK per ECMAScript, but then the SQL/JSON spec seems to be saying that only
>> double-quoted strings are allowed.  I'd rather be conservative about this
>> than get out in front of the spec and use syntax space that they might do
>> something else with someday.

I agree with erring on the side of the spec vs. what ECMAScript does. In
JSON, strings, identifiers, etc. are double-quoted. Anything that is
single quoted with throw an error in a compliant JSON parser.

Looking at the user documentation for how some other databases with
SQL/JSON support, this seems to back up your analysis.

> 
> The attached proposed patch makes these changes:
> 
> 1. Remove support for single-quoted literals in jsonpath.
> 
> 2. Treat an unrecognized escape (e.g., "\z") as meaning the escaped
>    character, rather than throwing an error.
> 
> 3. A few cosmetic adjustments to make the jsonpath_scan code shorter and
>    clearer (IMHO).

If this refers to s/any/other/, yes I would agree it's clearer.

> As for #1, although the SQL/JSON tech report does reference ECMAScript
> which allows both single- and double-quoted strings, it seems to me
> that their intent is to allow only the double-quoted variant.  They
> specifically reference JSON string literals at one point, and of course
> JSON only allows double-quoted.  Also, all of their discussion and
> examples use double-quoted.  Plus you'd have to be pretty nuts to want
> to use single-quoted when writing a jsonpath string literal inside a SQL
> literal (and the tech report seems to contemplate that jsonpaths MUST be
> string literals, though of course our implementation does not require
> that).

I agree with the above (though wrt single-quoting and literals, I have
seen stranger things).

> As for #2, the existing code throws an error, but this is contrary
> to clear statements in every single one of the relevant standards.

Makes sense.

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?

Jonathan