Re: Move defaults toward ICU in 16? - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: Move defaults toward ICU in 16?
Date
Msg-id d62b2874-729b-d26a-2d0a-0d64f509eca4@enterprisedb.com
Whole thread Raw
In response to Re: Move defaults toward ICU in 16?  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: Move defaults toward ICU in 16?  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On 25.02.23 00:54, Jeff Davis wrote:
> On Fri, 2023-02-17 at 15:07 -0800, Jeff Davis wrote:
>> 2. Update the pg_database entry for template0. This has less
>> potential
>> for surprise in case people are actually using template0 for a
>> template.
> 
> New patches attached.
> 
>    0001: default autoconf to build with ICU (meson already uses 'auto')

I would skip this.  There was a brief discussion about this at [0], 
where I pointed out that if we are going to do something like that, 
there would be other candidates among the optional dependencies to 
promote, such as certainly openssl and arguably lz4.  If we don't do 
this consistently across dependencies, then there will be confusion.

In practice, I don't think it matters.  Almost all installations are 
made by packagers, who will make their own choices.  Flipping the 
default in configure is only going to cause some amount of confusion and 
annoyance in some places, but won't actually have the ostensibly desired 
impact in practice.

[0]: 
https://www.postgresql.org/message-id/flat/534fed4a262fee534662bd07a691c5ef%40postgrespro.ru

>    0002: update template0 in new cluster (as described above)

This makes sense.  I'm confused what the code originally wanted to 
achieve, e.g.,

-/*
- * Check that every database that already exists in the new cluster is
- * compatible with the corresponding database in the old one.
- */
-static void
-check_databases_are_compatible(void)

Was there once support for the new cluster having additional databases 
in place?  Weird.

In any case, I think you can remove additional code from get_db_infos() 
related to fields that are no longer used, such as db_encoding, and the 
corresponding struct fields in DbInfo.

>    0003: default initdb to use ICU

What are the changes in the citext tests about?  Is it the same issue as 
in unaccent?  In that case, the OR should be an AND?  Maybe add a comment?

Why is unaccent is "broken" if the default collation is provided by ICU 
and LC_CTYPE=C?  Is that a general problem?  Should we prevent this 
combination?

What are the changes in the ecpg tests about?  Looks harmless, but if 
there is a need, maybe it should be commented somewhere, otherwise what 
prevents someone from changing it back?




pgsql-hackers by date:

Previous
From: Önder Kalacı
Date:
Subject: Re: [PATCH] Use indexes on the subscriber when REPLICA IDENTITY is full on the publisher
Next
From: Peter Eisentraut
Date:
Subject: Re: Refactoring SysCacheGetAttr to know when attr cannot be NULL