On 8/9/17 14:07, Tom Lane wrote:
> 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 understand this concern, but I don't know how to solve it. Any string
(more or less), is valid as an ICU locale name. In order to create some
initial collations, we ask ICU, give me a list of distinct locales with
their canonical names. That's the list we use. The next version of ICU
gives us a different list. There is no way to tell the API, no, I meant
the list you gave me last time.
The only way to solve that problem directly is to preload no locales.
Even the idea of maintaining a list of locales by hand cannot guarantee
that things won't go away in the future.
I think it is better in the long run that we acknowledge that the list
of preloaded collations will change (it already happens with glibc), and
we develop some guidance on how to deal with that. As mentioned in
another message, I don't foresee a fully automatic solution, however.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
