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

From: "David E. Wheeler" <[email-masked]>
Date: Sat, 31 Jan 2026 09:44:13 -0500

On Jan 4, 2026, at 15:51, David E. Wheeler <[email-masked]> wrote:

> Updated and rebased patch attached.

New rebase on 6918434. See also the PR[0].

The Commitfest app still shows this patch as “Needs review”[1]. It has had a number of reviews, most recently from jian. Any objection to changing it to “Ready for Committer”?

Best,

David

[0] https://github.com/theory/postgres/pull/12
[1] https://commitfest.postgresql.org/patch/5270/

---

From: Florents Tselai <[email-masked]>
Date: Sat, 31 Jan 2026 18:23:27 +0200

> > Updated and rebased patch attached.

I think your attachment was left behind. Attaching it myself (that's v17,
right? ) checked out from your PR

> The Commitfest app still shows this patch as “Needs review”[1]. It has had
> a number of reviews, most recently from jian. Any objection to changing it
> to “Ready for Committer”?

With the refactoring you’ve done across the parser and executor,
I’m already tempted to slip in a few more string methods - but I think we
should leave that for a future iteration.
Functionally, it’d just mean adding another branch in
executeStringInternalMethod,
and I’d rather keep this patch focused.

At this point, I’d say it’s ready for committer review.

That said, I do expect someone to raise (again) the question of
how we want to handle potential future conflicts with the SQL/JSON
standard.
That’s a broader design topic, and it’s going to come up every time we
extend the JSONPath language.

And yes, I’m obviously biased here - I already have two other patches in
the same spirit queued up, namely
https://commitfest.postgresql.org/patch/6429/
https://commitfest.postgresql.org/patch/6436/

---

From: "David E. Wheeler" <[email-masked]>
Date: Sat, 31 Jan 2026 11:31:08 -0500

On Jan 31, 2026, at 11:23, Florents Tselai <[email-masked]> wrote:

> I think your attachment was left behind. Attaching it myself (that's v17, right? ) checked out from your PR

Bah! Yes, thank you.

> I’m already tempted to slip in a few more string methods - but I think we should leave that for a future iteration.
> Functionally, it’d just mean adding another branch in executeStringInternalMethod, 

Agreed.

> how we want to handle potential future conflicts with the SQL/JSON standard. 
> That’s a broader design topic, and it’s going to come up every time we extend the JSONPath language.

Yup, continual challenge, part of the deal IME.

> And yes, I’m obviously biased here - I already have two other patches in the same spirit queued up, namely

Ha! Message received, I’ll try to find some time to look at them.

D

---

From: "David E. Wheeler" <[email-masked]>
Date: Sun, 1 Feb 2026 10:23:58 -0500

>> At this point, I’d say it’s ready for committer review. 

Me too, I’ve updated the status[0].

  [0]: https://commitfest.postgresql.org/patch/5270/

Best,

David

---

From: "David E. Wheeler" <[email-masked]>
Date: Sat, 28 Mar 2026 10:30:42 -0400

On Mar 28, 2026, at 06:04, Andrew Dunstan <[email-masked]> wrote:

> I have fixed that. Some key_name entries were missing, which was an issue. I also removed some unused variables and some duplicate tests, and did some general tidying.

Looks good to me! I’m curious what the implication of missing `key_name`s was, since the tests passed and all the functions worked. Can we create additional tests that would fail when the keys were missing?

D

---

From: Andrew Dunstan <[email-masked]>
Date: Sat, 28 Mar 2026 11:02:13 -0400

> Looks good to me! I’m curious what the implication of missing `key_name`s was, since the tests passed and all the functions worked. Can we create additional tests that would fail when the keys were…

The key_name production is what allows a keyword to also be used as an 
object key in $.keyname syntax. The trim keywords (ltrim, rtrim, btrim) 
were added there, so $.ltrim as a key works. But $.lower,
$.upper, $.initcap, $.replace, and $.split_part as keys would all break.

There are tests added for it.

cheers

andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com

---

From: Andrew Dunstan <[email-masked]>
Date: Thu, 2 Apr 2026 15:21:54 -0400

On 2026-03-28 Sa 11:58 AM, David E. Wheeler wrote:
> On Mar 28, 2026, at 11:02, Andrew Dunstan<[email-masked]> wrote:
>
>> The key_name production is what allows a keyword to also be used as an object key in $.keyname syntax. The trim keywords (ltrim, rtrim, btrim) were added there, so $.ltrim as a key works. But $.lower,
> Ooh, right. It has been so long since I looked at this stuff that I forgot. Thanks for the reminder.
>
> And for this!

Committed.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com

---

From: Florents Tselai <[email-masked]>
Date: Thu, 2 Apr 2026 22:57:28 +0300

On Thu, Apr 2, 2026 at 10:21 PM Andrew Dunstan <[email-masked]> wrote:

> On Mar 28, 2026, at 11:02, Andrew Dunstan <[email-masked]> <[email-masked]> wrote:
>
>
Boom! Thanks so much for this.

---

From: Marcos Pegoraro <[email-masked]>
Date: Thu, 2 Apr 2026 18:10:59 -0300

> Committed.
There is a typo here.
<literal>jsonb_path_query('"xyxtrimyyx"', '$.btrim("xyz")')</literal>
should be
<literal>jsonb_path_query('"xyztrimxyz"', '$.btrim("xyz")')</literal>

regards
Marcos

---

From: Andrew Dunstan <[email-masked]>
Date: Fri, 3 Apr 2026 07:51:46 -0400

On 2026-04-02 Th 5:10 PM, Marcos Pegoraro wrote:
> Em qui., 2 de abr. de 2026 às 16:22, Andrew Dunstan 
> <[email-masked]> escreveu:
>
>     Committed.
>
> There is a typo here.

Good catch, will fix.

Thanks

cheers

andrew

---

From: Andrew Dunstan <[email-masked]>
Date: Fri, 3 Apr 2026 09:36:31 -0400

>> <literal>jsonb_path_query('"xyztrimxyz"', '$.btrim("xyz")')</literal>

On second thoughts, I don't think this is a typo. btrim() removes 
leading and trailing sequences of any characters in the argument string.:

andrew@~=# select jsonb_path_query('"xyxtrimyyx"', '$.btrim("xyz")');
  jsonb_path_query
------------------
  "trim"
(1 row)

cheers

andrew

---

From: Marcos Pegoraro <[email-masked]>
Date: Fri, 3 Apr 2026 11:34:57 -0300

Em sex., 3 de abr. de 2026 às 10:36, Andrew Dunstan <[email-masked]>
escreveu:

> On second thoughts, I don't think this is a typo. btrim() removes leading
> and trailing sequences of any characters in the argument string.
>
Regression has this, so you are correct.
select jsonb_path_query('"zzzytest"', '$.ltrim("xyz")');
 jsonb_path_query
------------------
 "test"

I always thought that only those with exactly the same string would be
removed, but thinking char by char, then it makes perfect sense.
And it works like string trim functions, so everything's fine.
Sorry for the noise.

regards
Marcos