| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Shay Rojansky <roji(at)roji(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Should AT TIME ZONE be volatile? |
| Date: | 2021-11-11 17:07:36 |
| Message-ID: | 1571659.1636650456@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> writes:
> On Thu, 2021-11-11 at 09:52 -0500, Tom Lane wrote:
>> Yup. If we had reliable ways to detect changes in this sort of
>> environment-supplied data, maybe we could do something about it
>> (a la the work that's been happening on attaching collation versions
>> to indexes). But personally I can't summon the motivation to work
>> on that, when ICU is the *only* such infrastructure that offers
>> readily program-readable versioning.
> Nobody will want to hear that, but the only really good solution would
> be for PostgreSQL to have its own built-in collations.
And our own tzdb too? Maybe an outfit like Oracle has the resources
and will to maintain their own copies of such data, but I can't see
us wanting to do it.
tzdb has an additional problem, which is that not updating is not an
option: if you're affected by a DST law change, you want that update,
and you frequently need it yesterday. We're definitely not set up
to handle that sort of update process, which is why we recommend
--with-system-tzdata.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2021-11-11 17:15:03 | RecoveryInProgress() has critical side effects |
| Previous Message | Tom Lane | 2021-11-11 16:52:49 | Re: Strange error in new 003_cic_2pc.pl test |