On Wed, Mar 5, 2025 at 2:30 PM Florents Tselai <florents.tse...@gmail.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
