> On 13 May 2025, at 2:07 PM, David E. Wheeler <da...@justatheory.com> wrote: > > On May 9, 2025, at 15:50, Robert Haas <robertmh...@gmail.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.
