Re: Avoiding possible future conformance headaches in JSON work - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Avoiding possible future conformance headaches in JSON work
Date
Msg-id 17740.1568932524@sss.pgh.pa.us
Whole thread Raw
In response to Re: Avoiding possible future conformance headaches in JSON work  (Chapman Flack <chap@anastigmatix.net>)
Responses Re: Avoiding possible future conformance headaches in JSON work
List pgsql-hackers
Chapman Flack <chap@anastigmatix.net> writes:
> 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.

Just to not leave this thread hanging --- the discussion was picked up
in this other thread:

https://www.postgresql.org/message-id/flat/CAPpHfdvDci4iqNF9fhRkTqhe-5_8HmzeLt56drH%2B_Rv2rNRqfg%40mail.gmail.com

and I think we've come to the conclusion that the only really awful regex
compatibility problem is differing interpretations of the 'x' flag, which
we solved temporarily by treating that as unimplemented in jsonpath.
There are some other unimplemented features that we can consider adding
later, too.  (Fortunately, Spencer's engine throws errors for all of
those, so adding them won't create new compatibility issues.)  And we did
add some documentation:

https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=0a97edb12ec44f8d2d8828cbca6dd7639408ac88

There remains the question of whether we should do something like
requiring a "pg" prefix to allow access to the other nonstandard
features we added to jsonpath.  I see the point that the SQL committee
might well add something pretty similar in future.  But I'm not too
concerned about that, on two grounds: (1) the same argument could be
raised against *every* non-spec feature we have or ever will have;
(2) now that Peter's in on SQL committee deliberations, we have a
chance to push for any future spec changes to not be unnecessarily
incompatible.  So my inclination is to close this open item as
sufficiently done, once the minor lexer issues raised in the other
thread are done.

            regards, tom lane



pgsql-hackers by date:

Previous
From: "Jonathan S. Katz"
Date:
Subject: Re: Define jsonpath functions as stable
Next
From: Chapman Flack
Date:
Subject: Re: Avoiding possible future conformance headaches in JSON work