Re: arbitrary "interval" expression OK with "at time zone" but not with "set time zone" — Why?

From: Bryn Llewellyn <bryn(at)yugabyte(dot)com>
To: Tom Lane PostgreSQL <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-general list <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: arbitrary "interval" expression OK with "at time zone" but not with "set time zone" — Why?
Date: 2021-06-03 22:10:31
Message-ID: 1DF73C1D-B801-447A-8997-E4B7C5B41EE3@yugabyte.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Thanks, as ever, Tom, for the quick response. I’ll summarize your explanation as “Yes, there is indeed a logical parsing paradox”. Or, as you said, as “the SQL Standard committee—the gift that keeps on giving”.

> Tom wrote:
>
>> Bryn wrote:
>>
>> The "at time zone" clause that can decorate a timetsamp[tz] value seems to allow an argument that’s an arbitrary expression that yields a value whose data type is "interval".
>
> AT TIME ZONE is part of the SQL expression syntax, thus it's unsurprising that its arguments can be arbitrary subexpressions.
>
>> set time zone '-7 hours'::interval;
>> brings a "42601: syntax error".
>
> The SET statement, on the other hand, most definitely does not accept expressions of any kind; only simple literals. That's in line with most other utility commands in Postgres, but there are particularly good reasons to be wary of trying to generalize SET. Cases such as SET TRANSACTION ISOLATION LEVEL have to be able to execute without a transaction context at all.
>
> Yeah, it's asymmetric :-(. But the SQL committee has gifted us with a pretty asymmetric language, plus there are various implementation constraints that are not that easy to get rid of.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bryn Llewellyn 2021-06-03 22:35:29 inner subprograms ... Was: syntax question
Previous Message Tom Lane 2021-06-03 22:08:42 Re: possible license violations