Re: CREATE COLLATION definitional questions for ICU

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: CREATE COLLATION definitional questions for ICU
Date: 2017-06-30 18:04:56
Message-ID: d6f6859e-b88f-a80c-6f08-fe0069f00c88@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-06-30 18:09:53 Re: "SELECT *" vs hidden columns and logical column order
Previous Message Peter Eisentraut 2017-06-30 17:38:12 Re: CREATE COLLATION definitional questions for ICU