Gregory Stark <[EMAIL PROTECTED]> writes: > Of course it would still be better if we could get it closer to ColId. YEAR > MONTH DAY HOUR MINUTE SECOND the only problem spots? How much else had to > change to work around other conflicts?
No, to make it ColId we'd also have to reserve all of these: CHAR_P CHARACTER DOUBLE_P VARYING WITH WITHOUT and even that doesn't seem to get us quite out of the woods, as there's still a reduce/reduce conflict here: state 2523 1118 character: CHARACTER . opt_varying 1744 reserved_keyword: CHARACTER . VARYING shift, and go to state 1350 ')' reduce using rule 1125 (opt_varying) ')' [reduce using rule 1744 (reserved_keyword)] ',' reduce using rule 1125 (opt_varying) ',' [reduce using rule 1744 (reserved_keyword)] $default reduce using rule 1125 (opt_varying) opt_varying go to state 1356 which I'm not sure how to get rid of. A possibly bigger problem is that the solution for postfix ops doesn't scale nicely: we'd have to list not only IDENT, but *every* can-be-ColId keyword, in the %precedence list, which (a) is a maintenance headache, (b) causes a conflict because some are already listed there with the wrong precedence for this purpose, and (c) is very scary from the viewpoint of possibly silently suppressing warnings of future grammar ambiguities. I'm not even that happy with giving IDENT a precedence; giving precedences to 270 or so currently precedence-less tokens just doesn't sound safe. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match