From: | "Jonathan S(dot) Katz" <jkatz(at)postgresql(dot)org> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Chapman Flack <chap(at)anastigmatix(dot)net>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Define jsonpath functions as stable |
Date: | 2019-09-17 15:38:28 |
Message-ID: | 1f1034bc-4f66-4331-f111-c3c2d1f7d46a@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 9/16/19 6:39 PM, Jonathan S. Katz wrote:
> My main question is "where" -- I'm thinking somewhere in the JSON
> path[2] section. After reading your email 3 times, I may have enough
> knowledge to attempt some documentation on the regexp in JSON path.
Here is said attempt to document. Notes:
- I centered it around the specification for LIKE_REGEX, which uses
XQuery, but primarily noted where our implementation of POSIX regex's
differs from what is specified for LIKE_REGEX vis-a-vis XQuery
- I put the pith of the documentation in a subsection off of "POSIX
regular expressions"
- I noted that LIKE_REGEX is specified in SQL:2008, which I read on the
Internet(tm) but was not able to confirm in the spec as I do not have a copy
- For my explanation about the "x" flag differences, I talked about how
we extended it, but I could not capture how Tom described the nuances above.
- From the SQL/JSON path docs, I added a section on regular expressions
stating what the behavior is, and referring back to the main regex docs
- I removed the "x" flag being supported for like_regex in JSON path
I also presume it needs a bit of wordsmithing / accuracy checks, but
hope it's a good start and does not require a massive rewrite.
Thanks,
Jonathan
Attachment | Content-Type | Size |
---|---|---|
regex.patch | text/plain | 5.9 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-09-17 15:49:21 | Re: logical decoding : exceeded maxAllocatedDescs for .spill files |
Previous Message | Tom Lane | 2019-09-17 15:17:32 | Re: Nondeterministic collations vs. text_pattern_ops |