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
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 |