On 06/14/24 22:29, Chapman Flack wrote:
> So I should go look at our code to see what grammar we've implemented,
> exactly. It is beginning to seem as if we have simply added
> <JSON path predicate> as another choice for an expression, not restricted
> to only appearing in a filter. If so, and we add documentation about how
> we diverge from the standard, that's probably the way to say it.
That's roughly what we've done:
119 result:
120 mode expr_or_predicate {
121 ...
125 }
126 | /* EMPTY */ { *result = NULL; }
127 ;
128
129 expr_or_predicate:
130 expr { $$ = $1; }
131 | predicate { $$ = $1; }
132 ;
Oddly, that's only at the top-level goal production. Your entire JSON
path query we'll allow to be a predicate in lieu of an expr. We still
don't allow a predicate to appear in place of an expr within any other
production.
Regards,
-Chap
