From: | Chapman Flack <jcflack(at)acm(dot)org> |
---|---|
To: | "David E(dot) Wheeler" <david(at)justatheory(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: jsonpath: Missing regex_like && starts with Errors? |
Date: | 2024-06-15 03:21:52 |
Message-ID: | 666D08D0.1020204@acm.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2024-06-15 06:59:49 | Re: strange context message in spi.c? |
Previous Message | Chapman Flack | 2024-06-15 02:29:34 | Re: jsonpath: Missing regex_like && starts with Errors? |