Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Erwin Brandstetter <brsaweda@gmail.com>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>,
Jeff Janes <jeff.janes@gmail.com>,
PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
Date: 2023-10-24T00:53:12Z
Lists: pgsql-bugs
Erwin Brandstetter <brsaweda@gmail.com> writes: > On Thu, 19 Oct 2023 at 21:01, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Hmm ... looks like we *are* following the standard: >> ... >> The text mentions that "the second operand is permitted to be an SQL/JSON >> sequence and to support existential semantics", whereas they evidently >> don't want that for a regex pattern. > So input from "vars" cannot be substituted into the jsonpath expression > after "like_regex" (as opposed to all other jsonpath operators). Seems > pretty random from a user's perspective. I agree it looks pretty random if you haven't drilled down into the spec's fine print. Personally I wouldn't be opposed to extending the spec here (not that I'm volunteering to write the patch). Nosing around in jsonpath_gram.y, I see datetime_template as the only other place where there's a random-seeming choice to allow STRING_P but not VARIABLE_P. Should we tackle that too? regards, tom lane