Re: Missing docs on AT TIME ZONE precedence?

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, Shay Rojansky <roji(at)roji(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Missing docs on AT TIME ZONE precedence?
Date: 2023-11-27 16:35:25
Message-ID: 202311271635.4xpb63uidueu@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2023-Nov-26, Tom Lane wrote:

> I am, however, feeling a little bit on the warpath about the
> grammar comments for the SQL/JSON keyword precedences:
>
> /* SQL/JSON related keywords */
> %nonassoc UNIQUE JSON
> %nonassoc KEYS OBJECT_P SCALAR VALUE_P
> %nonassoc WITH WITHOUT
>
> Every other case where we're doing this has a para of explanation
> in the block comment just below here. These not only have no
> meaningful explanation, they are in the wrong place --- it looks
> like they are unrelated to the block comment, whereas actually
> (I think) they are another instance of it. I consider this
> well below project standard.

I introduced those in commit 6ee30209a6f1. That is the minimal set of
keywords for which the precedence had to be declared that was necessary
so that the grammar would compile for the new feature; I extracted that
from a much larger set that was in the original patch submission. I
spent a long time trying to figure out whether the block comment
applied, and I wasn't sure, so I ended up leaving the comment at what
you see there.

Looking at it again:

UNIQUE and KEYS are there for "WITH UNIQUE KEYS" (& WITHOUT), where KEYS
is optional and the whole clause is optional in some rules. So as I
understand it, we need to establish the relative precedence of UNIQUE
(first group), KEYS (second group) and WITH/WITHOUT (third group).
We also have a "%prec KEYS" declaration in the
json_key_uniqueness_constraint_opt rule for this.

We also need a relative precedence between JSON and the set below:
VALUE, OBJECT, SCALAR, for the "IS JSON {VALUE/OBJECT/SCALAR}"
construct.

I put KEYS in the same set as the three above just because it was not a
problem to do so; likewise UNIQUE together with JSON. (I think it would
also work to put WITH and WITHOUT in the second group, but I only ran
bison to verify this, didn't run any tests.)

I am also not sure if the current location of those three groups (or
two, if we merge those) relative to the rest of the groups below the
large block comment is a good one. As far as compilability of the
grammar goes, it looks like they could even be at the very bottom of the
precedence list, below the join operators.

--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"¿Qué importan los años? Lo que realmente importa es comprobar que
a fin de cuentas la mejor edad de la vida es estar vivo" (Mafalda)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2023-11-27 17:13:59 Re: walwriter interacts quite badly with synchronous_commit=off
Previous Message jian he 2023-11-27 16:28:50 Re: PATCH: Add REINDEX tag to event triggers