Re: Avoiding possible future conformance headaches in JSON work

On 09/19/19 18:35, Tom Lane wrote:

> 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;

This should not be read as a violent objection, but I do think that
point (1) glosses over a, well, possibly salient difference in likelihood:

Sure, against *every* non-spec feature we have or ever will have, someone
/could/ raise a generic "what if SQL committee might add something pretty
similar in future".

But what we have in this case are specific non-spec features (array, map,
and sequence constructors, lambdas, map/fold/reduce, user-defined
functions) that are flat-out already present in the current version of
the language that the SQL committee is clearly modeling jsonpath on.

That might raise the likelihood of collision in this case above its
usual, universal cosmic background level.

Regards,
-Chap