Re: Range Types and extensions - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Range Types and extensions
Date
Msg-id BANLkTimT0qecKObBXumaKTWhSJoaFjneVA@mail.gmail.com
Whole thread Raw
In response to Re: Range Types and extensions  (Florian Pflug <fgp@phlo.org>)
Responses Re: Range Types and extensions
List pgsql-hackers
On Sun, Jun 12, 2011 at 7:53 AM, Florian Pflug <fgp@phlo.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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Boolean operators without commutators vs. ALL/ANY
Next
From: Robert Haas
Date:
Subject: Re: Boolean operators without commutators vs. ALL/ANY