On Tue, May 13, 2025 at 11:00 PM David E. Wheeler <da...@justatheory.com> wrote:
> On May 13, 2025, at 16:24, Florents Tselai <florents.tse...@gmail.com> wrote:
> > 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.
>
> I get the pragmatism, and don’t want to over-bike-shed, but what a wart to
> live with. [I just went back and re-read Robert’s post, and didn’t realize he
> used exactly the same expression!] Would it really be too effortful to create
> _stable or _volatile functions and leave the _tz functions as a sort of
> legacy?
No, that wouldn't be too much work, but the issue is that people will
keep using the _tz versions and when we eventually try to remove them
those people will complain no matter how prominent we make the
deprecation notice. If we want to go this route, maybe we should do
something like:
1. Add the new versions with a _s suffix or whatever.
2. Invent a GUC jsonb_tz_warning = { on | off } that advises you to
use the new functions instead, whenever you use the old ones.
3. After N years, flip the default value from off to on.
4. After M additional years, remove the old functions and the GUC.
5. Still get complaints.
--
Robert Haas
EDB: http://www.enterprisedb.com
