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

From Jeff Davis
Subject Re: Built-in CTYPE provider
Date
Msg-id 1d178eb1bbd61da1bcfe4a11d6545e9cdcede1d1.camel@j-davis.com
Whole thread Raw
In response to Re: Built-in CTYPE provider  (Noah Misch <noah@leadboat.com>)
Responses Re: Built-in CTYPE provider
List pgsql-hackers
On Thu, 2024-07-04 at 14:26 -0700, Noah Misch wrote:
> I think you're saying that if some Unicode update changes the results
> of a
> STABLE function but does not change the result of any IMMUTABLE
> function, we
> may as well import that update.  Is that about right?  If so, I
> agree.

If you are proposing that Unicode updates should not be performed if
they affect the results of any IMMUTABLE function, then that's a new
policy.

For instance, the results of NORMALIZE() changed from PG15 to PG16 due
to commit 1091b48cd7:

  SELECT NORMALIZE(U&'\+01E030',nfkc)::bytea;

  Version 15: \xf09e80b0

  Version 16: \xd0b0

I am neither endorsing nor opposing the new policy you propose at this
time, but deep in the sub-thread of one particular feature is not the
right place to discuss it.

Please start a new thread for the proposed PG18 policy change and CC
me. I happen to think that around the release of the next version of
Unicode (in a couple months) would be the most productive time to have
that discussion, but you can start the discussion now if you like.

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Should we document how column DEFAULT expressions work?
Next
From: "David G. Johnston"
Date:
Subject: Re: Should we document how column DEFAULT expressions work?