pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Noah Misch <noah@leadboat.com>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Peter Eisentraut <peter@eisentraut.org>
Cc: Daniel Verite <daniel@manitou-mail.org>
Cc: Jeremy Schneider <schneider@ardentperf.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Built-in CTYPE provider
Date: Thu, 18 Jul 2024 13:03:31 -0400
Message-ID: <3729436.1721322211@sss.pgh.pa.us> (raw)
In-Reply-To: <f29686018b4432a8ae2e535dbe19f0d88e7a79d5.camel@j-davis.com>
References: <20240704212641.c4.nmisch@google.com>
	<1d178eb1bbd61da1bcfe4a11d6545e9cdcede1d1.camel@j-davis.com>
	<20240706195129.fd@rfd.leadboat.com>
	<564325.1720297161@sss.pgh.pa.us>
	<20240709010545.8c.nmisch@google.com>
	<39a30bd36198b44ed40da271ef96a72d133c32ba.camel@j-davis.com>
	<20240711125040.11.nmisch@google.com>
	<1908b19c0a3a210935608635cad1b4eeb819c66f.camel@j-davis.com>
	<20240717220326.df.nmisch@google.com>
	<4efae9f992f96a1e8eba0f515c637c3ff252d0fc.camel@cybertec.at>
	<20240718140015.9b.nmisch@google.com>
	<f29686018b4432a8ae2e535dbe19f0d88e7a79d5.camel@j-davis.com>

Jeff Davis <pgsql@j-davis.com> writes:
> On Thu, 2024-07-18 at 07:00 -0700, Noah Misch wrote:
>> Maybe someone will change
>> something in v18 so it's not like that, but don't count on it.

> That's backwards. If nothing happens in v18, then there will be no
> breaking Unicode change. It takes an active step by a committer to
> update Unicode.

This whole discussion seems quite bizarre to me.  In the first
place, it is certain that Unicode will continue to evolve, and
I can't believe that we'd just freeze pg_c_utf8 on the current
definition forever.  Whether the first change happens in v18
or years later doesn't seem like a particularly critical point.

In the second place, I cannot understand why pg_c_utf8 is being
held to a mutability standard that we have never applied to any
other locale-related functionality --- and indeed could not do
so, since in most cases that functionality has been buried in
libraries we don't control.  It seems to me to be already a
great step forward that with pg_c_utf8, at least we can guarantee
that the behavior won't change without us knowing about it.
Noah's desire to revert the feature makes the mutability situation
strictly worse, because people will have to continue to rely on
OS-provided functionality that can change at any time.

			regards, tom lane





view thread (125+ messages)  latest in thread

Message-ID: <3729436.1721322211@sss.pgh.pa.us>
Permalink:  ../3729436.1721322211@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/3729436.1721322211@sss.pgh.pa.us

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, pgsql@j-davis.com, noah@leadboat.com, laurenz.albe@cybertec.at, peter@eisentraut.org, daniel@manitou-mail.org, schneider@ardentperf.com, robertmhaas@gmail.com
  Subject: Re: Built-in CTYPE provider
  In-Reply-To: <3729436.1721322211@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox