Date: Mon, 1 Jul 2024 16:03:52 -0700
From: Noah Misch <noah@leadboat.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Peter Eisentraut <peter@eisentraut.org>,
	Daniel Verite <daniel@manitou-mail.org>,
	Robert Haas <robertmhaas@gmail.com>,
	Jeremy Schneider <schneider@ardentperf.com>,
	pgsql-hackers@postgresql.org
Subject: Re: Built-in CTYPE provider
Message-ID: <20240701230352.2c.nmisch@google.com>
References: <6bdb98e68b2b05aa71f7f934e227738eac84ecee.camel@j-davis.com>
 <19b34a70-f5cf-4faf-88dc-917db44ed48d@eisentraut.org>
 <846a7e1fa2024918b58ff7583523a2f3de9a11b4.camel@j-davis.com>
 <3117d30aa911b408b90420f4f280fa0c3b5851be.camel@j-davis.com>
 <4135cf11-206d-40ed-96c0-9363c1232379@eisentraut.org>
 <7451f81ba0cb512222ab759de8ca1cffe44e9acb.camel@j-davis.com>
 <1f309153-8198-4efa-86dd-8c304ec0040c@eisentraut.org>
 <a21b515000f121244db2a5570d4292d19df23379.camel@j-davis.com>
 <20240629220857.fb.nmisch@google.com>
 <1ecfeb4d2b1b7f119fa917d3052a3aecfaf4f425.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1ecfeb4d2b1b7f119fa917d3052a3aecfaf4f425.camel@j-davis.com>
User-Agent: Mutt/2.2.12 (2023-09-09)
Archived-At: <https://www.postgresql.org/message-id/20240701230352.2c.nmisch%40google.com>
Precedence: bulk

On Mon, Jul 01, 2024 at 12:24:15PM -0700, Jeff Davis wrote:
> On Sat, 2024-06-29 at 15:08 -0700, Noah Misch wrote:
> > lower(), initcap(), upper(), and regexp_matches() are
> > PROVOLATILE_IMMUTABLE.
> > Until now, we've delegated that responsibility to the user.  The user
> > is
> > supposed to somehow never update libc or ICU in a way that changes
> > outcomes
> > from these functions.
> 
> To me, "delegated" connotes a clear and organized transfer of
> responsibility to the right person to solve it. In that sense, I
> disagree that we've delegated it.

Good point.

> >   Now that postgresql.org is taking that responsibility
> > for builtin C.UTF-8, how should we govern it?  I think the above text
> > and [1]
> > convey that we'll update the Unicode data between major versions,
> > making
> > functions like lower() effectively STABLE.  Is that right?
> 
> Marking them STABLE is not a viable option, that would break a lot of
> valid use cases, e.g. an index on LOWER().

I agree.

> I don't think we need code changes for 17. Some documentation changes
> might be helpful, though. Should we have a note around LOWER()/UPPER()
> that users should REINDEX any dependent indexes when the provider is
> updated?

I agree the v17 code is fine.  Today, a user can (with difficulty) choose
dependency libraries so regexp_matches() is IMMUTABLE, as marked.  I don't
want $SUBJECT to be the ctype that, at some post-v17 version, can't achieve
that with unpatched PostgreSQL.  Let's change the documentation to say this
provider uses a particular snapshot of Unicode data, taken around PostgreSQL
17.  We plan never to change that data, so IMMUTABLE functions can rely on the
data.  If we provide a newer Unicode data set in the future, we'll provide it
in such a way that DDL must elect the new data.  How well would that suit your
vision for this feature?  An alternative would be to make pg_upgrade reject
operating on a cluster that contains use of $SUBJECT.