public inbox for [email protected]
help / color / mirror / Atom feedFrom: Alvaro Herrera <[email protected]>
To: Tom Lane <[email protected]>
Cc: Bruce Momjian <[email protected]>
Cc: Shay Rojansky <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Missing docs on AT TIME ZONE precedence?
Date: Mon, 27 Nov 2023 17:35:25 +0100
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
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)
view thread (9+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Missing docs on AT TIME ZONE precedence?
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox