Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Erwin Brandstetter <brsaweda(at)gmail(dot)com>
Cc: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, PostgreSQL Bug List <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex
Date: 2023-10-24 00:53:12
Message-ID: 460388.1698108792@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Erwin Brandstetter <brsaweda(at)gmail(dot)com> writes:
> On Thu, 19 Oct 2023 at 21:01, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2023-10-24 01:06:01 Re: AW: AW: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with relid xxxxx
Previous Message Peter Geoghegan 2023-10-24 00:45:39 Re: AW: AW: BUG #18147: ERROR: invalid perminfoindex 0 in RTE with relid xxxxx