Re: Should AT TIME ZONE be volatile?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Shay Rojansky <roji(at)roji(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Should AT TIME ZONE be volatile?
Date: 2021-11-10 14:49:35
Message-ID: 1437564.1636555775@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Shay Rojansky <roji(at)roji(dot)org> writes:
> It seems that PostgreSQL 14 allows using the AT TIME ZONE operator within
> generated column definitions; according to the docs, that means the
> operator is considered immutable. However, unless I'm mistaken, the result
> of AT TIME ZONE depends on the time zone database, which is external and
> can change. I think that means that generated column data can become
> out-of-date upon tz database changes.

Yeah, we generally don't take such hazards into account. The poster
child here is that if we were strict about this, text comparisons
couldn't be immutable, because the underlying collation rules can
(and do) change from time to time. That's obviously unworkable.

I'm not sure how big a deal this really is for timestamps. The actual
stored time is either UTC or local time, and those are generally pretty
well-defined. If you make the wrong choice of which one to store for
your use-case, you might be unhappy.

FWIW, I believe the text search operators are also labeled as if the
underlying configurations won't change, which of course isn't really true.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2021-11-10 14:52:06 Re: removing global variable ThisTimeLineID
Previous Message vignesh C 2021-11-10 14:31:40 Re: Removed unused import modules from tap tests