MIME-Version: 1.0
References: 
 <CA+v5N40sJF39m0v7h=QN86zGp0CUf9F1WKasnZy9nNVj_VhCZQ@mail.gmail.com>
 <145894.1727298237@sss.pgh.pa.us>
 <CAPpHfdtGhn_5jfLoepOScyqT+FXYB9QtV-OEprychDcMJco7mw@mail.gmail.com>
 <CA+v5N42PVJH3HbwLE1yC75XR6E5zGnCCdtSUXfgFwtGyPP8XYg@mail.gmail.com>
 <CA+Tgmob03B6h1SMsi7vs9uOX+vrqg_tyhh--mKC3BaTJ08qKYA@mail.gmail.com>
 <88A95900-E976-43BE-A73A-45AA75A11EE7@justatheory.com>
 <3682F2FE-AB57-4799-A439-7DA518E978A4@gmail.com>
 <F4AB5396-ACCA-4358-969E-6708C7F6A95A@justatheory.com>
In-Reply-To: <F4AB5396-ACCA-4358-969E-6708C7F6A95A@justatheory.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Wed, 21 May 2025 14:06:17 -0400
Message-ID: 
 <CA+Tgmoa-9tN85bEHfH7TBHa5uV1TwmZJEh_eYkLnwxOV=i6RSg@mail.gmail.com>
Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim,
 replace, split_part
To: "David E. Wheeler" <david@justatheory.com>
Cc: Florents Tselai <florents.tselai@gmail.com>,
 Alexander Korotkov <aekorotkov@gmail.com>,
	Tom Lane <tgl@sss.pgh.pa.us>,
 pgsql-hackers <pgsql-hackers@lists.postgresql.org>,
	Andrew Dunstan <andrew@dunslane.net>, Peter Eisentraut <peter@eisentraut.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BTgmoa-9tN85bEHfH7TBHa5uV1TwmZJEh_eYkLnwxOV%3Di6RSg%40mail.gmail.com>
Precedence: bulk

On Tue, May 13, 2025 at 11:00=E2=80=AFPM David E. Wheeler <david@justatheor=
y.com> wrote:
> On May 13, 2025, at 16:24, Florents Tselai <florents.tselai@gmail.com> wr=
ote:
> > As Robert said=E2=80=94and I agree=E2=80=94renaming the existing _tz fa=
mily would be more trouble than it=E2=80=99s worth, given the need for depr=
ecations, migration paths, etc. If we were designing this today, suffixes l=
ike _stable or _volatile might have been more appropriate, but at this poin=
t, we=E2=80=99re better off staying consistent with the _tz family.
>
> I get the pragmatism, and don=E2=80=99t want to over-bike-shed, but what =
a wart to live with. [I just went back and re-read Robert=E2=80=99s post, a=
nd didn=E2=80=99t realize he used exactly the same expression!] Would it re=
ally be too effortful to create _stable or _volatile functions and leave th=
e _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 =3D { 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.

--=20
Robert Haas
EDB: http://www.enterprisedb.com