Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex - Mailing list pgsql-bugs

From Tom Lane
Subject Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex
Date
Msg-id 3378578.1697742079@sss.pgh.pa.us
Whole thread Raw
In response to Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex  ("David G. Johnston" <david.g.johnston@gmail.com>)
Responses Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex
List pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> On Wed, Oct 18, 2023, 18:47 Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Oh, duh, makeItemLikeRegex() is expecting a plain JsonPathString,
>> and JsonPathParseItem.value.like_regex is set up for just a
>> constant pattern.  We could no doubt fix that, but it's a bigger
>> lift than I was hoping.

> Not in a position to do it myself but we should confirm we aren't simply
> following the standard here, and if so decide whether we want to deviate.

Hmm ... looks like we *are* following the standard:


<JSON like_regex predicate> ::=
  <JSON path wff> like_regex <JSON like_regex pattern>
      [ flag <JSON like_regex flags> ]
<JSON like_regex pattern> ::=
  <JSON path string literal>
<JSON like_regex flag> ::=
  <JSON path string literal>

whereas "starts with" has

<JSON starts with predicate> ::=
  <JSON starts with whole> starts with <JSON starts with initial>
<JSON starts with whole> ::=
  <JSON path wff>
<JSON starts with initial> ::=
  <JSON path wff>

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.


            regards, tom lane



pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: group by true now errors with non-integer constant in GROUP BY
Next
From: Robert Haas
Date:
Subject: Re: BUG #18146: Rows reappearing in Tables after Auto-Vacuum Failure in PostgreSQL on Windows