From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Florian Pflug <fgp(at)phlo(dot)org>, Martijn van Oosterhout <kleptog(at)svana(dot)org>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Darren Duncan <darren(at)darrenduncan(dot)net> |
Subject: | Re: Range Types and extensions |
Date: | 2011-06-20 15:09:28 |
Message-ID: | BANLkTi=VOTnkb9tD71RjXo1JwUhibVHvHXXAFyzv5=yZdOfsPw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Jun 20, 2011 at 3:17 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2011-06-20 15:11:14 | Re: POSIX question |
Previous Message | Andres Freund | 2011-06-20 15:09:16 | Re: POSIX question |