Re: Define jsonpath functions as stable

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
Cc: Chapman Flack <chap(at)anastigmatix(dot)net>, "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org>, Erik Rijkers <er(at)xs4all(dot)nl>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Define jsonpath functions as stable
Date: 2019-09-19 16:25:11
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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.

> 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.

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).

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

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

regards, tom lane

Attachment Content-Type Size
fix-jsonpath-lexer-issues-1.patch text/x-diff 15.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Isaac Morland 2019-09-19 16:26:27 Re: Usage of the system truststore for SSL certificate validation
Previous Message Robert Haas 2019-09-19 15:00:45 Re: backup manifests