Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part - Mailing list pgsql-hackers

From David E. Wheeler
Subject Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part
Date
Msg-id D57D3B5E-AF55-4F7F-9E55-FE06EE8ED811@justatheory.com
Whole thread Raw
In response to Re: PATCH: jsonpath string methods: lower, upper, initcap, l/r/btrim, replace, split_part  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On May 23, 2025, at 13:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:

>> I assume you mean that they’re set at initdb time, so there’s no mutability concern?
>
> Yeah, I think Peter's right and I'm wrong.  Obviously this ties into
> our philosophical debate about how immutable is immutable.  But as
> long as the functions only depend on locale settings that are fixed
> at database creation, I think it's okay to consider them immutable.
>
> If you were, say, depending on LC_NUMERIC, it would clearly be unsafe
> to consider that immutable, so I'm not quite sure if this is the end
> of the discussion.  But for what's mentioned in the thread title,
> I think we only care about LC_CTYPE.

Oh, so maybe all this is moot, and Florents can go ahead and add support for the functions to the non-_tz functions?

Should there be some sort of inventory of what functions can be used in what contexts?

D


Attachment

pgsql-hackers by date:

Previous
From: Sami Imseih
Date:
Subject: Re: queryId constant squashing does not support prepared statements
Next
From: Alexander Lakhin
Date:
Subject: Re: Non-reproducible AIO failure