On 13 May 2025, at 2:07 PM, David E. Wheeler <david@justatheory.com> wrote:
On May 9, 2025, at 15:50, Robert Haas <robertmhaas@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_tzfamily would be more trouble than it’s worth, given the need for deprecations, migration paths, etc. If we were designing this today, suffixes like_stableor_volatilemight have been more appropriate, but at this point, we’re better off staying consistent with the_tzfamily.
So the path forward seems to be:
- Put these new functions under thejsonb_path_*_tzfamily.
- Raise an error if they’re used in the non-_tzversions.
- Document this behavior clearly.
I’ll make sure to follow the patterns in the existing_tzfunctions closely.
Other thoughts and head’s up are, of course, welcome.
