Re: Should AT TIME ZONE be volatile? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Should AT TIME ZONE be volatile?
Date
Msg-id CA+TgmoZZXwj444svvVec53FWOm5z7mah0xR8-uYyFq9-dkj_NQ@mail.gmail.com
Whole thread Raw
In response to Re: Should AT TIME ZONE be volatile?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Should AT TIME ZONE be volatile?
List 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 by date:

Previous
From: Robert Haas
Date:
Subject: Re: Interrupts vs signals
Next
From: Tom Lane
Date:
Subject: Re: Should AT TIME ZONE be volatile?