Re: Range Types and extensions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <stark(at)mit(dot)edu>
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:33:06
Message-ID: 26722.1308583986@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Greg Stark <stark(at)mit(dot)edu> writes:
> 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.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2011-06-20 15:34:25 Re: Fwd: Keywords in pg_hba.conf should be field-specific
Previous Message Radosław Smogura 2011-06-20 15:30:31 Re: POSIX question