On Thu, Sep 26, 2024 at 1:55 PM Alexander Korotkov <aekorot...@gmail.com> wrote:
> On Thu, Sep 26, 2024 at 12:04 AM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Florents Tselai <florents.tse...@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? > > ------ > Regards, > Alexander Korotkov > Supabase > In case you're having a deja vu, while researching this I did come across [0] where disussing this back in 2019. In this patch I've conveniently left jspIsMutable and jspIsMutableWalker untouched and under the rug, but for the few seconds I pondered over this,the best answer I came with was a simple heuristic to what Alexander says above: if all elements are safe, then the whole jsp is immutable. If we really want to tackle this and make jsonpath richer though, I don't think we can avoid being a little more flexible/explicit wrt mutability. Speaking of extensible: the jsonpath standard does mention function extensions [1] , so it looks like we're covered by the standard, and the mutability aspect is an implementation detail. No? And having said that, the whole jsonb/jsonpath parser/executor infrastructure is extremely powerful and kinda under-utilized if we use it "only" for jsonpath. Tbh, I can see it supporting more specific DSLs and even offering hooks for extensions. And I know for certain I'm not the only one thinking about this. See [2] for example where they've lifted, shifted and renamed the jsonb/jsonpath infra to build a separate language for graphs [0] https://www.postgresql.org/message-id/capphfdvdci4iqnf9fhrktqhe-5_8hmzelt56drh+_rv2rnr...@mail.gmail.com [1] https://www.rfc-editor.org/rfc/rfc9535.html#name-function-extensions [2] https://github.com/apache/age/blob/master/src/include/utils/agtype.h
