Re: Should AT TIME ZONE be volatile?

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Should AT TIME ZONE be volatile?
Дата
Msg-id CA+TgmoZZXwj444svvVec53FWOm5z7mah0xR8-uYyFq9-dkj_NQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Should AT TIME ZONE be volatile?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Should AT TIME ZONE be volatile?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Wed, Nov 10, 2021 at 6:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> For comparison's sake, glibc have modified their
> collation rules significantly (enough for us to hear complaints about
> it) at least twice in the past decade.  That's considerably *more*
> frequent than DST law changes where I live.

Yes. It seems to be extremely common for people to get hosed by
collation changes. Different major versions of RHEL ship with
different collations. Different minor versions of RHEL ship with
different collations. Tiny little changes in very end of the glibc
version number include collation changes. I believe that it's been
explicitly stated by Ulrich Drepper that you should not rely on
collation definitions not to change at any time, and that relying on
them for any sort of on-disk ordering is nuts. Which seems like an
insane idea, because (1) surely the only point of such definitions is
to help you sort your data, and you probably don't want to resort it
in a continuous loop in case somebody decided to change the collation
definition under you and (2) how important can it be to continually
tinker with the sorting rules?

I'm not really convinced that ICU is better, either. I think it's more
that it isn't used as much.

I don't have any constructive proposal for what to do about any of
this. It sure is frustrating, though.

-- 
Robert Haas
EDB: http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Interrupts vs signals
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Should AT TIME ZONE be volatile?