Re: Add support for AT LOCAL

From: Vik Fearing <vik(at)postgresfriends(dot)org>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Add support for AT LOCAL
Date: 2023-06-06 08:24:55
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 6/6/23 03:56, Laurenz Albe wrote:
> On Mon, 2023-06-05 at 23:13 -0400, Vik Fearing wrote:
>> The Standard defines time zone conversion as follows:
>> <datetime factor> ::=
>>    <datetime primary> [ <time zone> ]
>> <time zone> ::=
>>    AT <time zone specifier>
>> <time zone specifier> ::=
>>      LOCAL
>>    | TIME ZONE <interval primary>
>> While looking at something else, I noticed we do not support AT LOCAL.
>> The local time zone is defined as that of *the session*, not the server,
>> which can make this quite interesting in views where the view will
>> automatically adjust to the session's time zone.
>> Patch against 3f1aaaa180 attached.
> +1 on the idea; it should be faily trivial, if not very useful.


> At a quick glance, it looks like you resolve "timezone" at the time
> the query is parsed. Shouldn't the resolution happen at query
> execution time?

current_setting(text) is stable, and my tests show that it is calculated
at execution time.

postgres=# prepare x as values (now() at local);
postgres=# set timezone to 'UTC';
postgres=# execute x;
2023-06-06 08:23:02.088634
(1 row)

postgres=# set timezone to 'Asia/Pyongyang';
postgres=# execute x;
2023-06-06 17:23:14.837219
(1 row)

Am I missing something?
Vik Fearing

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Lakhin 2023-06-06 09:00:00 Re: TRAP: FailedAssertion("prev_first_lsn < cur_txn->first_lsn", File: "reorderbuffer.c", Line: 927, PID: 568639)
Previous Message 謝東霖 2023-06-06 08:18:30 Re: Improve join_search_one_level readibilty (one line change)