Re: jsonpath: Missing regex_like && starts with Errors?

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

In response to

Browse pgsql-hackers by date

  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?