Peter Geoghegan <pg@bowt.ie> writes:
> On Wed, Aug 9, 2017 at 10:35 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> In other words, excluding, say, emoji collations from what gets
>> imported is just making a value judgement that those collations aren't
>> important and people shouldn't want to use them.
> Yes, it is. I think that's fine, though. Other database systems that
> use ICU for collations do this. Without exception, I think.
Actually, I don't think that's the issue at all. People are free to
make other ICU collations if they want to. My point is that we should
encourage them to do that, rather than depend on initdb-provided
collations, because manually-created collations are much more certain
to move across version upgrades safely. If we were sure that
pg_import_system_collations would produce pretty much the same set of
collation names with future ICU releases as it does with current ones,
then there would be no issue --- but the evidence at hand suggests the
opposite. I want to do something to address that stability issue before
it comes back to bite us.
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.
regards, tom lane
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs