Greg Stark <st...@mit.edu> writes: > On Mon, Jun 20, 2011 at 3:17 PM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers