Peter Eisentraut <peter.eisentraut@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
