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: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Erwin Brandstetter <brsaweda(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex
Date: 2023-10-19 01:46:29
Message-ID: 3241895.1697679989@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Jeff Janes <jeff(dot)janes(at)gmail(dot)com> writes:
> On Wed, Oct 18, 2023 at 5:20 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Maybe it wouldn't take more than s/STRING_P/starts_with_initial/
>> here (though I'd then rename starts_with_initial to something
>> more generic).

> I tried it, and it didn't work. No error, it just doesn't match
> anything--including literal values which do match things in HEAD.

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.

> Maybe the problem is that the regex pattern is compiled at the same time
> the jsonpath is compiled?

Doesn't look that way to me: executeLikeRegex is just using
RE_compile_and_execute every time. (It's "caching" a text datum
representing the pattern string, which might be a good candidate for
the silliest use of caching I've ever seen in PG; it's surely not
buying any useful increment of performance.)

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message David G. Johnston 2023-10-19 02:13:16 Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex
Previous Message Tom Lane 2023-10-19 00:48:03 Re: Insufficient memory access checks in pglz_decompress