On 6/27/17 11:17, Tom Lane wrote: > Moreover, if you insist on defining it this way, it's going to limit > our freedom of action in future. It's possible that, either in some > future version of ICU or for some other provider, there could be more > than one version of a collation simultaneously available.
Good point, but I think this is highly theoretical and would probably work differently and separately from what we have now. If someone invented a feature that allows linking against multiple versions of ICU at once (thus allowing old versions to be continued to be used), then you'd still want the safety check of the current style that the version currently in use is the one previously used. If ICU offered a way to use multiple collation versions from the same library version, then I'd imagine that you would select the version with an attribute in the locale name, not with a separate field. And arguably, considering how the ICU locale name resolution works, having a safety check that records the actual version would still be of use. So "the version I want" and "the version I got" would continue to be separate attributes. I would not mind a gentle renaming of the current functionality if it could make that clearer. > Lastly, I'm not seeing the use-case for having CREATE COLLATION magically > make a working collation from a broken one. Wouldn't you normally > expect to need to do ALTER COLLATION REFRESH on an obsolete collation > before doing anything with it? My question would be, what's the use case for doing it the other way around? Thinking of an analogy, if there is a table with an index that is somehow affected by pg_upgrade and needs reindexing after pg_upgrade, and I run CREATE TABLE LIKE to make a new table like that old table, would it create the new table in a state that it would also require reindexing before it can be used? That doesn't seem very useful. -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers