Re: Built-in CTYPE provider - Mailing list pgsql-hackers

From Noah Misch
Subject Re: Built-in CTYPE provider
Date
Msg-id 20240702230333.8d.nmisch@google.com
Whole thread Raw
In response to Re: Built-in CTYPE provider  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Built-in CTYPE provider
Re: Built-in CTYPE provider
List pgsql-hackers
On Wed, Jul 03, 2024 at 12:05:09AM +0200, Peter Eisentraut wrote:
> On 02.07.24 18:51, Noah Misch wrote:
> > On Mon, Jul 01, 2024 at 06:19:08PM -0700, Jeff Davis wrote:
> > > On Mon, 2024-07-01 at 16:03 -0700, Noah Misch wrote:
> > > >    An alternative would be to make pg_upgrade reject
> > > > operating on a cluster that contains use of $SUBJECT.
> > > 
> > > That wouldn't help anyone.
> > 
> > Can you say more about that?  For the last decade at least, I think our
> > standard for new features has been to error rather than allow an operation
> > that creates a known path to wrong query results.  I think that's a helpful
> > standard that we should continue to follow.
> 
> I don't think the builtin locale provider is any different in this respect
> from the other providers:  The locale data might change and there is a
> version mechanism to track that.  We don't prevent pg_upgrade in scenarios
> like that for other providers.

Each packager can choose their dependencies so the v16 providers don't have
the problem.  With the $SUBJECT provider, a packager won't have that option.



pgsql-hackers by date:

Previous
From: Noah Misch
Date:
Subject: Re: collect_corrupt_items_vacuum.patch
Next
From: Melanie Plageman
Date:
Subject: Re: Vacuum ERRORs out considering freezing dead tuples from before OldestXmin