On Thu, Sep 26, 2024 at 1:55 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
On Thu, Sep 26, 2024 at 12:04 AM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Florents Tselai <florents.tselai@gmail.com> writes: > > This patch is a follow-up and generalization to [0]. > > It adds the following jsonpath methods: lower, upper, initcap, l/r/btrim, > > replace, split_part. > > How are you going to deal with the fact that this makes jsonpath > operations not guaranteed immutable? (See commit cb599b9dd > for some context.) Those are all going to have behavior that's > dependent on the underlying locale. > > We have the kluge of having separate "_tz" functions to support > non-immutable datetime operations, but that way doesn't seem like > it's going to scale well to multiple sources of mutability.
While inventing "_tz" functions I was thinking about jsonpath methods and operators defined in standard then. Now I see huge interest on extending that. I wonder if we can introduce a notion of flexible mutability? Imagine that jsonb_path_query() function (and others) has another function which analyzes arguments and reports mutability. If jsonpath argument is constant and all methods inside are safe then jsonb_path_query() is immutable otherwise it is stable. I was thinking about that back working on jsonpath, but that time problem seemed too limited for this kind of solution. Now, it's possibly time to shake off the dust from this idea. What do you think?
I was thinking about taking another stab at this.
Would someone more versed in the inner workings of jsonpath like to weigh in on the immutability wrt locale?
