From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Range Types and extensions |
Date: | 2011-06-13 04:00:08 |
Message-ID: | BANLkTimT0qecKObBXumaKTWhSJoaFjneVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jun 12, 2011 at 7:53 AM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>> I think the collation is going to have to be baked into the type
>> definition, no? You can't just up and change the collation of the
>> column as you could for a straight text column, if that might cause
>> the contents of some rows to be viewed as invalid.
>
> Now you've lost me. If a text range is simply a pair of strings,
> as I suggested, and collations are applied only during comparison
> and RANGE_EMPTY(), why would the collation have to be baked into
> the type?
>
> If you're referring to the case
> (1) Create table with text-range column and collation C1
> (2) Add check constraint containing RANGE_EMPTY()
> (3) Add data
> (4) Alter column to have collation C2, possibly changing
> the result of RANGE_EMPTY() for existing ranges.
> then that points to a problem with ALTER COLUMN.
No, I'm saying that you might have a column containing '[a, Z)', and
someone might change the collation of the column from en_US to C.
When the collation was en_US, the column could legally contain that
value, but now that the collation is C, it can't. ALTER TABLE isn't
going to recheck the validity of the data when someone changes the
collation: that's only supposed to affect the sort order, not the
definition of what is a legal value.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-06-13 04:00:51 | Re: Boolean operators without commutators vs. ALL/ANY |
Previous Message | Tom Lane | 2011-06-13 03:44:51 | Re: Boolean operators without commutators vs. ALL/ANY |