Re: Define jsonpath functions as stable

Jonathan S. Katz <jkatz@postgresql.org>

From: "Jonathan S. Katz" <jkatz@postgresql.org>
To: Erik Rijkers <er@xs4all.nl>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Chapman Flack <chap@anastigmatix.net>, pgsql-hackers@lists.postgresql.org
Date: 2019-09-17T17:58:31Z
Lists: pgsql-hackers

Attachments

On 9/17/19 12:09 PM, Erik Rijkers wrote:
> On 2019-09-17 17:38, Jonathan S. Katz wrote:
>> [regex.patch]

Thanks for the review!

> "Several other parts of the SQL standard
> also define LIKE_REGEX equivalents that refer
> to this implementation, including the
> SQL/JSON path like_regex filter."
> 
> As I understand this text, 'concept' seems better.
> I'd drop 'also', too.

I rewrote this to be:

"Several other parts of the SQL standard refer to the LIKE_REGEX
specification to define similar operations, including..."

> 2.
> 'whereas the POSIX will those'  should be
> 'whereas POSIX will regard those'
>  or maybe 'read those'

I used "treat those"

> 
> 3.
> +     The SQL/JSON standard borrows its definition for how regular
> expressions
> +     from the <literal>LIKE_REGEX</literal> operator, which in turns
> uses the
> +     XQuery standard.
> That sentence needs the verb 'work', no?  'for how regular expressions
> work [..]'
> Or alternatively drop 'how'.

I dropped the "how".

v2 attached. Thanks!

Jonathan

Commits

  1. Fix some minor spec-compliance issues in jsonpath lexer.

  2. Doc: improve documentation around jsonpath regular expressions.

  3. Fix bogus handling of XQuery regex option flags.