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?
------
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
