Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part

On Wed, Mar 5, 2025 at 2:30 PM Florents Tselai
<florents(dot)tselai(at)gmail(dot)com> wrote:
> 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?

I'm not sure the issues with immutability here are particularly
related to jsonpath -- I think they may just be general problems with
our framework for immutability.

I always struggle a bit to remember our policy on these issues -- to
the best of my knowledge, we haven't documented it anywhere, and I
think we probably should. I believe the way it works is that whenever
a function depends on the operating system's timestamp or locale
definitions, we decide it has to be stable, not immutable. We don't
expect those things to be updated very often, but we know sometimes
they do get updated.

Now apparently what we've done for time zones is we have both
json_path_exists and json_path_exists_tz, and the former only supports
things that are truly immutable while the latter additionally supports
things that depend on time zone, and are thus marked stable.

I suppose we could just add support for these locale-dependent
operations to the "tz" version and have them error out in the non-tz
version. After all, the effect of depending on time zone is, as far as
I know, the same as the effect of depending on locale: the function
can't be immutable any more. The only real problem with that idea, at
least to my knowledge, is that the function naming makes you think
that it's just about time zones and not about anything else. Maybe
that's a wart we can live with?

Tom writes earlier in the thread that:

# 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.

But I'm not sure I understand why it matters that there are multiple
sources of mutability here. Maybe I'm missing a piece of the puzzle
here.

--
Robert Haas
EDB: http://www.enterprisedb.com