Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex
| От | Tom Lane |
|---|---|
| Тема | Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex |
| Дата | |
| Msg-id | 460388.1698108792@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Variable substitution in jsonb functions fails for jsonpath operator like_regex (Erwin Brandstetter <brsaweda@gmail.com>) |
| Список | 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
В списке pgsql-bugs по дате отправления: