On Wed, Aug 9, 2017 at 2:07 PM, 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.
Yeah, that idea has some appeal.
> But even if we had that, I'm
> dubious that having hundreds of collations present by default is really
> all that user-friendly.
The flip side is that it's not clear to me how the user is supposed to
discover possibly-useful collations that don't show up in
pg_collation. The documentation for CREATE COLLATION says only that
"The available choices depend on the operating system and build
options." Section 23.2.2.2 says "With ICU, it is not sensible to
enumerate all possible locale names. ICU uses a particular naming
system for locales, but there are many more ways to name a locale than
there are actually distinct locales. (In fact, any string will be
accepted as a locale name.)" So, there's no guidance on how to pick a
string that will work, and no error if you pick one that doesn't.
Wahoo!
I assume that this is in fact the whole point of putting any
ICU-related entries in pg_collation at all -- or for that matter any
libc-related entries. If it were easy to guess what parameters you
might want to provide to CREATE COLLATION, we could just let users
create the collations they happen to need and it would be only a minor
inconvenience. As it is, removing things from pg_collation seems to
make them all but undiscoverable.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
