Re: Avoiding possible future conformance headaches in JSON work

On 6/18/19 12:51 PM, Oleg Bartunov wrote:
>> have 'pg lax $.map(x => x + 10)'.
>
> This is exactly what we were thinking about !

Perfect!

>> specify a POSIX re. Or, as like_regex has a named-parameter-like
>> syntax--like_regex("abc" flag "i")--perhaps 'posix' should just be
>> an extra keyword in that grammar: like-regex("abc" posix). That would
>> be safe from the committee adding a P flag that means something else.
>
> We didn't think about regex, I don't know anybody working on xquery.

I do. :)

But is that even the point? It's already noted in [1] that the standard
calls for one style of regexps and we're providing another.

It's relatively uncomplicated now to add some kind of distinguishing
syntax for our posix flavor of like_regex. Yes, it would be a change
between beta1 and final release, but that doesn't seem unheard-of.

In contrast, if such a distinction is not added now, we know that will
be a headache for any future effort to more closely conform to the
standard. Whether such a future effort seems near-term or far off, it
doesn't seem strategic to make current choices that avoidably make it
harder.

Aside: I just looked over the 12 doco to see if the note in [1] is
in there, and all I see is that 'like_regex' is documented as "Tests
pattern matching with POSIX regular expressions."

In my opinion, that ought to have a note flagging that as different
from the standard. The user experience is not so good if someone comes
assuming we conform to the standard, writes code, then has to learn
why it didn't work. The whole doc section [2] about XML is intended
to spare people from unwelcome discoveries of that sort, but it was
written after the fact. I think it's better to have it from the start.

[1]
https://github.com/obartunov/sqljsondoc/blob/master/jsonpath.md#sqljson-conformance

[2] https://www.postgresql.org/docs/12/xml-limits-conformance.html