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
- regex-v2.patch (text/plain) patch v2
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
-
Fix some minor spec-compliance issues in jsonpath lexer.
- e56cad84d542 13.0 landed
- 5f3bec0769c1 12.0 landed
-
Doc: improve documentation around jsonpath regular expressions.
- b9cf94c8c249 12.0 landed
- 0a97edb12ec4 13.0 landed
-
Fix bogus handling of XQuery regex option flags.
- d5b90cd64855 13.0 landed
- 148881454208 12.0 landed