Re: Range Types and extensions

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Range Types and extensions
Дата
Msg-id BANLkTimT0qecKObBXumaKTWhSJoaFjneVA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Range Types and extensions  (Florian Pflug <fgp@phlo.org>)
Ответы Re: Range Types and extensions  (Darren Duncan <darren@darrenduncan.net>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Boolean operators without commutators vs. ALL/ANY
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Boolean operators without commutators vs. ALL/ANY