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

> On 13 May 2025, at 2:07 PM, David E. Wheeler <david(at)justatheory(dot)com> wrote:
>
> On May 9, 2025, at 15:50, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
>> # 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.
>
> I read that to mean “we’re not going to add another json_path_exists_* function for every potentially immutable JSONPath function. But I take your point that it could be generalized for *any* mutable function. In which case maybe it should be renamed?
>
> Best,
>
> David
>

We discussed this a bit during the APFS:

As Robert said—and I agree—renaming the existing _tz family would be more trouble than it’s worth, given the need for deprecations, migration paths, etc. If we were designing this today, suffixes like _stable or _volatile might have been more appropriate, but at this point, we’re better off staying consistent with the _tz family.

So the path forward seems to be:

- Put these new functions under the jsonb_path_*_tz family.

- Raise an error if they’re used in the non-_tz versions.

- Document this behavior clearly.

I’ll make sure to follow the patterns in the existing _tz functions closely.

Other thoughts and head’s up are, of course, welcome.

Patch CF entry: https://commitfest.postgresql.org/patch/5270/

Last updated Sept 24, so it will also need a rebase to account for changes in jsonpath_scan.l. I’ll get to that shortly.