On 9/19/19 6:18 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 9/19/19 3:48 PM, Tom Lane wrote:
>>> Seems like
>>> the error handling in jsonpath_gram.y could use some cleanup too
>>> ... although I don't think it's a task to tackle while we're
>>> rushing to get v12 shippable.
>
>> IIRC
"Jonathan S. Katz" writes:
> On 9/19/19 3:48 PM, Tom Lane wrote:
>> Seems like
>> the error handling in jsonpath_gram.y could use some cleanup too
>> ... although I don't think it's a task to tackle while we're
>> rushing to get v12 shippable.
> IIRC if we want to change the contents of an error
On 9/19/19 3:48 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> 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?
>
> I thought about that, but it seems like it'd be memori
"Jonathan S. Katz" writes:
> 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?
I thought about that, but it seems like it'd be memorializing some
other weird behavior:
regressio
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.
>> I
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
> har
Chapman Flack writes:
> On 09/18/19 17:12, Tom Lane wrote:
>> As such, I think this doesn't apply to SQL/JSON. The SQL/JSON spec
>> seems to defer to Javascript/ECMAscript for syntax details, and
>> in either of those languages you have backslash escape sequences
>> for writing weird characters,
On 09/18/19 17:12, Tom Lane wrote:
> After further reading, it seems like what that text is talking about
> is not actually a regex feature, but an outgrowth of the fact that
> the regex pattern is being expressed as a string literal in a language
> for which XML character entities are a native as
"Jonathan S. Katz" writes:
> On 9/17/19 6:40 PM, Tom Lane wrote:
>> After a re-read of the XQuery spec, it seems to me that the character
>> entry form that they have and we don't is actually "&#;" like
>> HTML, rather than just "#NN". Can anyone double-check that?
> Clicking through the XQu
On Wed, Sep 18, 2019 at 4:13 AM Jonathan S. Katz wrote:
> Here is a v4. I added some more paragraphs the bullet point that
> explains the different flags to make it feel a bit less dense.
Sorry that I didn't participate this discussion till now. FWIW, I
agree with selected approach to document d
On 9/17/19 10:00 PM, Chapman Flack wrote:
> On 09/17/19 21:13, Jonathan S. Katz wrote:
>
>> to), which describes being able to use "&#[0-9]+;" and "&#[0-9a-fA-F]+;"
>
> Er, that is, "&#[0-9]+;" and "&#x[0-9a-fA-F]+;" (with x for the hex case).
Correct, I missed the "x".
Thanks,
Jonathan
sig
On 09/17/19 21:13, Jonathan S. Katz wrote:
> to), which describes being able to use "&#[0-9]+;" and "&#[0-9a-fA-F]+;"
Er, that is, "&#[0-9]+;" and "&#x[0-9a-fA-F]+;" (with x for the hex case).
>> Does
>> it work outside bracket expressions, or only inside?
>
> Looking at the parse tree (start
On 9/17/19 6:40 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> v2 attached. Thanks!
>
> I whacked this around some (well, quite a bit actually);
So I see :) Thanks.
> notably,
> I thought we'd better describe things that are in our engine but
> not XQuery, as well as vice-versa.
Yeah, tha
"Jonathan S. Katz" writes:
> v2 attached. Thanks!
I whacked this around some (well, quite a bit actually); notably,
I thought we'd better describe things that are in our engine but
not XQuery, as well as vice-versa.
After a re-read of the XQuery spec, it seems to me that the character
entry form
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."
>
On 2019-09-17 17:38, Jonathan S. Katz wrote:
On 9/16/19 6:39 PM, Jonathan S. Katz wrote:
[regex.patch]
A few things/typos caught my eye:
1.
'implementation' seems the wrong word in sentence:
"Several other parts of the SQL standard
also define LIKE_REGEX equivalents that refer
to this impleme
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:
-
On 09/16/19 17:10, Tom Lane wrote:
> I was initially troubled
> by the fact that XML Schema regexps are implicitly anchored, ie must
> match the whole string; that's a huge difference from POSIX. However,
> 19075-6 says that jsonpath like_regex works the same as the LIKE_REGEX
> predicate in SQL;
On 9/16/19 5:10 PM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> On 9/16/19 11:20 AM, Tom Lane wrote:
>>> I think we could possibly get away with not having any special marker
>>> on regexes, but just explaining in the documentation that "features
>>> so-and-so are not implemented". Writing th
"Jonathan S. Katz" writes:
> On 9/16/19 11:20 AM, Tom Lane wrote:
>> I think we could possibly get away with not having any special marker
>> on regexes, but just explaining in the documentation that "features
>> so-and-so are not implemented". Writing that text would require closer
>> analysis t
On 9/16/19 11:20 AM, Tom Lane wrote:
> "Jonathan S. Katz" writes:
>> It sounds like the easiest path to completion without potentially adding
>> futures headaches pushing back the release too far would be that, e.g.
>> these examples:
>
>> $.** ? (@ like_regex "O(w|v)" pg flag "i")
>> $
"Jonathan S. Katz" writes:
> It sounds like the easiest path to completion without potentially adding
> futures headaches pushing back the release too far would be that, e.g.
> these examples:
> $.** ? (@ like_regex "O(w|v)" pg flag "i")
> $.** ? (@ like_regex "O(w|v)" pg)
> If it's
Hi,
On 7/29/19 8:33 PM, Chapman Flack wrote:
> On 07/29/19 18:27, Alexander Korotkov wrote:
>
>> What do you think about renaming existing operator from like_regex to
>> pg_like_regex? Or introducing special flag indicating that PostgreSQL
>> regex engine is used ('p' for instance)?
>
> Renamin
On 07/29/19 18:27, Alexander Korotkov wrote:
> What do you think about renaming existing operator from like_regex to
> pg_like_regex? Or introducing special flag indicating that PostgreSQL
> regex engine is used ('p' for instance)?
Renaming the operator is simple and certainly solves the problem
On Mon, Jul 29, 2019 at 5:55 PM Chapman Flack wrote:
> On 7/29/19 10:25 AM, Alexander Korotkov wrote:
>
> > * like_regex predicate uses our regular expression engine, which
> > deviates from standard.
>
> I still favor adding some element to the syntax (like a 'posix' or 'pg'
> keyword in the gra
On Mon, Jul 29, 2019 at 5:36 PM Tom Lane wrote:
> > However, we've spotted some deviations between standard and our
> > implementation.
> > * like_regex predicate uses our regular expression engine, which
> > deviates from standard.
> > * We always do numeric computations using numeric datatype
Hi,
On 7/29/19 10:25 AM, Alexander Korotkov wrote:
> * like_regex predicate uses our regular expression engine, which
> deviates from standard.
I still favor adding some element to the syntax (like a 'posix' or 'pg'
keyword in the grammar for like_regex) that identifies it as using
a different
Alexander Korotkov writes:
> During my work on bringing jsonpath patchset to commit, I was always
> keeping in mind that we need to make jsonb_path_*() functions
> immutable. Having these functions immutable, users can build
> expression indexes over them.
Right.
> However, we've spotted some d
28 matches
Mail list logo
