From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
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 20:34:24 |
Message-ID: | 4006949.1701117264@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> (TBH I don't think the added comments really explain the problems fully.
> That's most likely because I don't actually understand what the problems
> are.)
The actual problem is that nobody has applied a cluestick to the SQL
committee about writing an unambiguous grammar :-(. But I digress.
I don't like the existing coding for more reasons than just
underdocumentation. Global assignment of precedence is a really,
really dangerous tool for solving ambiguous-grammar problems, because
it can mask problems unrelated to the one you think you are solving:
basically, it eliminates bison's complaints about grammar ambiguities
related to the token you mark. (Commits 12b716457 and 28a61fc6c are
relevant here.) Attaching precedence to individual productions is
far safer, because it won't have any effect that extends beyond that
production. You still need a precedence attached to the lookahead
token; but I think we should try very hard to not assign a precedence
different from IDENT's to any unreserved keywords.
After a bit of fooling around I found a patch that seems to meet
that criterion; attached.
regards, tom lane
Attachment | Content-Type | Size |
---|---|---|
fix-json-precedence-hazards.patch | text/x-diff | 3.3 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2023-11-27 20:38:24 | Re: pgsql: meson: docs: Add {html,man} targets, rename install-doc-* |
Previous Message | Jeff Davis | 2023-11-27 20:29:47 | Re: proposal: change behavior on collation version mismatch |