public inbox for [email protected]  

help / color / mirror / Atom feed

From: Florents Tselai <[email protected]>
To: David E. Wheeler <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Alexander Korotkov <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Andrew Dunstan <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
Date: Tue, 13 May 2025 16:24:11 -0400
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <CA+v5N40sJF39m0v7h=QN86zGp0CUf9F1WKasnZy9nNVj_VhCZQ@mail.gmail.com>
	<[email protected]>
	<CAPpHfdtGhn_5jfLoepOScyqT+FXYB9QtV-OEprychDcMJco7mw@mail.gmail.com>
	<CA+v5N42PVJH3HbwLE1yC75XR6E5zGnCCdtSUXfgFwtGyPP8XYg@mail.gmail.com>
	<CA+Tgmob03B6h1SMsi7vs9uOX+vrqg_tyhh--mKC3BaTJ08qKYA@mail.gmail.com>
	<[email protected]>



> On 13 May 2025, at 2:07 PM, David E. Wheeler <[email protected]> wrote:
> 
> On May 9, 2025, at 15:50, Robert Haas <[email protected]> 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 _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.

So the path forward seems to be:

- Put these new functions under the jsonb_path_*_tz family.

- Raise an error if they’re used in the non-_tz versions.

- Document this behavior clearly.

I’ll make sure to follow the patterns in the existing _tz functions closely.

Other thoughts and head’s up are, of course, welcome.

Patch CF entry: https://commitfest.postgresql.org/patch/5270/

Last updated Sept 24, so it will also need a rebase to account for changes in jsonpath_scan.l. I’ll get to that shortly.

view thread (56+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox