Greg Stark <stark@mit.edu> writes:
> On Mon, Jun 20, 2011 at 3:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Given the need to deal with multiple collations for collatable types,
>> I'd say it's not so much "unfortunate" as "utterly unworkable". �At
>> least unless you give up the notion of binding the collation into the
>> type definition ... which has other issues, per discussion a few days
>> ago. �Even ignoring collations, I really think we want to allow multiple
>> range types for base types that have multiple btree sort orderings.
> I was imagining it would be not part of the type but part of the
> internal data in the range type. The dumped representation would look
> something like ['bar','baz',''en_US'] and input forms like
> ['bar','baz'] would just default to the database default collation or
> the session's default collation or whatever.
> The most disturbing thing about this is that it would make
> unrestorable dumps if any of those collation names change or are not
> installed before the data is loaded. It's kind of like having your
> table names embedded in a text column in your tables. It could make
> things awkward to manage later.
Yeah. In particular this would cause issues for pg_upgrade, which would
have to somehow ensure that collation OIDs didn't change between old and
new installations, which is just about impossible given the current
method for assigning them. I think we need to avoid that, really.
regards, tom lane