Re: Move definition of standard collations from initdb to pg_collation.dat - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Move definition of standard collations from initdb to pg_collation.dat
Date
Msg-id 3440245.1680003186@sss.pgh.pa.us
Whole thread Raw
In response to Move definition of standard collations from initdb to pg_collation.dat  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Move definition of standard collations from initdb to pg_collation.dat  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
> While working on [0], I was wondering why the collations ucs_basic and 
> unicode are not in pg_collation.dat.  I traced this back through 
> history, and I think this was just lost in a game of telephone.
> The initial commit for pg_collation.h (414c5a2ea6) has only the default 
> collation in pg_collation.h (pre .dat), with initdb handling everything 
> else.  Over time, additional collations "C" and "POSIX" were moved to 
> pg_collation.h, and other logic was moved from initdb to 
> pg_import_system_collations().  But ucs_basic was untouched.  Commit 
> 0b13b2a771 rearranged the relative order of operations in initdb and 
> added the current comment "We don't want to pin these", but looking at 
> the email[1], I think this was more a guess about the previous intent.

Yeah, I was just loath to change the previous behavior in that
patch.  I can't see any strong reason not to pin these entries.

> I suggest we fix this now; see attached patch.

While we're here, do we want to adopt some other spelling of "the
root locale" than "und", in view of recent discoveries about the
instability of that on old ICU versions?

            regards, tom lane



pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: "variable not found in subplan target list"
Next
From: Tom Lane
Date:
Subject: Re: "variable not found in subplan target list"