On Wed, Aug 9, 2017 at 11:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I suppose a different way to address this would be to make pg_upgrade
> smart enough to deal with the situation, by creating ICU collations
> that are used in the source installation but are missing from the
> initdb-provided set in the target. But even if we had that, I'm
> dubious that having hundreds of collations present by default is really
> all that user-friendly.
Let's try to get to a proposal that we'll all be happy with.
The base locale names, which include regional variants like Austrian
German, are as stable as possible. pg_import_system_collations()
should just add those. If anything changes there, it's because the
locale literally ceases to exist for political reasons (it is subject
to a 5 year CLDR deprecation policy when this happens). Not much point
in worrying about that. You said yourself that these seemed stable.
Separately, there could be a new SQL-callable function that advertises
what ICU says it makes available, melded into a valid collation name,
in the style of today's pg_import_system_collations(). This could ask
ucol_getKeywordValuesForLocale() to get only "commonly used [variant]
values with the given locale" for a specified base locale (system
pg_collation OID?), or it could also show every possible variant.
We'd encourage users to investigate the variants within the
documentation, including giving specific examples of what is generally
possible. There could be practical examples of why the user might
actually want to create, say, a phonebook collation, or a traditional
Spanish collation.
--
Peter Geoghegan
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
