Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 2019-09-20 01:14, Tom Lane wrote:
>> Sure. But we also modeled those features on the same language that the
>> committee is looking at (or at least I sure hope we did). So it's
>> reasonable to assume that they would come out at the same spot without
>> any prompting. And we can prompt them ;-).
> Also, I understand these are features proposed for PG13, not in PG12.
> So while this is an important discussion, it's not relevant to the PG12
> release, right?
> (If so, I'm content to close these open items.)
I took a quick look to compare our jsonpath documentation with
ISO/IEC TR_19075-6_2017 (I did *not* try to see if the code agrees
with the docs ;-)). As far as I can see, everything described in
our docs appears in the TR, with the exception of two things
that are already documented as Postgres extensions:
1. Recursive (multilevel) wildcards, ie .** and .**{level [to level]}
accessors, per table 8.25.
2. We allow a path expression to be a Boolean predicate, although the TR
allows predicates only in filters, per example in 9.16.1:
'$.track.segments[*].HR < 70'
(It's not exactly clear to me why this syntax is necessary; what's
it do that you can't do more verbosely with a filter?)
I have no opinion on whether we're opening ourselves to significant
spec-compliance risks through these two features. I am, however,
unexcited about adding some kind of "PG only" marker to the language,
for a couple of reasons. First, I really doubt that a single boolean
flag would get us far in terms of dealing with future compliance
issues. As soon as we have two extension features (i.e., already)
we have the question of what happens if one gets standardized and
the other doesn't; and that risk gets bigger if we're going to add
half a dozen more things. Second, we've procrastinated too long
and thereby effectively made a decision already. At this point
I don't see how we could push in any such change without delaying
the release.
So my vote at this point is "ship it as-is".
regards, tom lane
