Peter Eisentraut <peter.eisentr...@2ndquadrant.com> writes: > On 6/25/17 11:45, Tom Lane wrote: >> * Should not the FROM code path copy the old collation's version? >> It seems a little bit weird that "cloning" a collation takes the >> liberty of installing a new version.
> I think this is working correctly. Specifying the version explicitly is > really only useful for pg_upgrade, because it needs to reproduce the > state that is on disk. When you create a new collation, you want to > work with the collation version that the currently running software > provides. Hm. I certainly buy that for the "long form" of CREATE COLLATION, but it seems to me that the charter of CREATE COLLATION FROM is to clone the source collation's properties exactly. The C.C. ref page says that in so many words: The name of an existing collation to copy. The new collation will have the same properties as the existing one, but it ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ will be an independent object. 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. In that scenario, if an existing collation object referred to one of those available versions, it would be quite surprising for CREATE COLLATION FROM to silently substitute another one. But we'd be kind of stuck with doing that if we allow this precedent to be set in v10. 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? regards, tom lane -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers