From: | sulfinu(at)gmail(dot)com |
---|---|
To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: The jsonpath predicate `like_regex` does not accept variables for pattern (or flags) |
Date: | 2024-08-06 20:19:15 |
Message-ID: | CAGH1kmy4_Gszu1r9A0b5FtpaqgguUDHQhrT0xjBv+EhJUYCHgw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Looks like I didn't make myself undestood: I do *not* produce the regular
expression dynamically (on a side note, I would have to be careful to
escape the right stuff, regardless of SQL or jsonpath). It is the WHERE
clause of the query that I build dynamically. That's why I would like the
pattern to be submitted as a variable, (which I anyway employ with a "q"
flag).
*Question:* is there another way to express the *contains* predicate in
jsonpath?
În mar., 6 aug. 2024 la 20:49, David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
a scris:
> You can use a format function to build it dynamically. Unfortunately it
> is a bit of a pain since you need to do escaping; which is a pain for
> regex. SQL scope doesn't have this problem so moving your logic outside of
> a json is should seriously be considered before trying to construct dynamic
> jsonpath expressions.
>
> I get the impression we are conforming to a standard here so even
> proposing a patch to change this behavior would require some convincing to
> deviate from the standard on this point. Though I could see adding a new
> format escape and related quote_jsonpathliteral function to be something
> we'd be more open to in order to make dynamic json path expressions more
> easily doable.
>
> David J.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-08-06 20:55:15 | Re: BUG #18571: A CTE with a DELETE auxiliary statement only deletes when the DELETE results are referenced later |
Previous Message | PG Bug reporting form | 2024-08-06 20:02:42 | BUG #18572: Crash during postgresql-16.3-2-windows-x64.exe installation |