Re: Missing docs on AT TIME ZONE precedence?
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Bruce Momjian <bruce@momjian.us>, Shay Rojansky <roji@roji.org>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2023-11-27T20:34:24Z
Lists: pgsql-hackers
Attachments
- fix-json-precedence-hazards.patch (text/x-diff) patch
Alvaro Herrera <alvherre@alvh.no-ip.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
Commits
-
Clean up usage of bison precedence for non-operator keywords.
- a916b47e2329 17.0 landed
-
Doc: list AT TIME ZONE and COLLATE in operator precedence table.
- 3558f120f869 17.0 landed
- c7bd476049ca 15.6 landed
- 9033e7019821 16.2 landed
- 69a9134326f2 13.14 landed
- 648fc6a1c459 14.11 landed
- 450ad6585ac5 12.18 landed
-
SQL/JSON: support the IS JSON predicate
- 6ee30209a6f1 16.0 cited