Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part

From: "David E(dot) Wheeler" <david(at)justatheory(dot)com>
To: Florents Tselai <florents(dot)tselai(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
Date: 2025-05-14 03:00:34
Message-ID: F4AB5396-ACCA-4358-969E-6708C7F6A95A@justatheory.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On May 13, 2025, at 16:24, Florents Tselai <florents(dot)tselai(at)gmail(dot)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?

Or maybe there’s a nice backronym we could come up with for _tz.

Best,

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2025-05-14 03:45:53 Re: Backward movement of confirmed_flush resulting in data duplication.
Previous Message Richard Guo 2025-05-14 02:13:56 Re: Memoize ANTI and SEMI JOIN inner