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

From: Florents Tselai <florents(dot)tselai(at)gmail(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
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>
Subject: Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
Date: 2025-05-23 17:06:25
Message-ID: 01DC1C38-0692-461B-AA63-5394330356BE@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On 22 May 2025, at 11:56 PM, Peter Eisentraut <peter(at)eisentraut(dot)org> wrote:
>
> On 09.05.25 21:50, Robert Haas wrote:
>> I always struggle a bit to remember our policy on these issues -- to
>> the best of my knowledge, we haven't documented it anywhere, and I
>> think we probably should. I believe the way it works is that whenever
>> a function depends on the operating system's timestamp or locale
>> definitions, we decide it has to be stable, not immutable. We don't
>> expect those things to be updated very often, but we know sometimes
>> they do get updated.
>
> I don't understand how this discussion got to the conclusion that functions that depend on the locale cannot be immutable. Note that the top-level functions lower, upper, and initcap themselves are immutable.

I assume you mean that they’re set at initdb time, so there’s no mutability concern?

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-05-23 17:39:15 Re: Why our Valgrind reports suck
Previous Message Masahiko Sawada 2025-05-23 16:40:23 Re: Assert("vacrel->eager_scan_remaining_successes > 0")