"Christopher Kings-Lynne" <chriskl@familyhealth.com.au> writes:
> Yep, tried it again and everything passes.
Bingo.
>> I'm betting this is not a platform issue, but just aclchk.c being out
>> of sync with the parser. GrantStmt is using parser token codes to
>> distinguish the various kinds of GRANT, which is probably a bad idea.
>> The token codes will change anytime someone looks crosseyed at gram.y
>> (well, I exaggerate, but they're not exactly stable). IMHO node
>> structure definitions shouldn't depend on them.
Looking around finds these places where parser token codes are used
beyond the parser itself:
aclchk.c: GrantStmt
command.c: AlterTableDropConstraint
comment.c: CommentObject, CommentRelation
postgres.c: TransactionStmt
utility.c: TransactionStmt, FetchStmt, CopyStmt, DefineStmt, ReindexStmt
(I exclude _outAExpr in outfuncs.c, which is okay since it's effectively
only used for debugging dumps.)
I believe these are all trouble waiting to happen --- for example,
if utility.o is out of sync with the parser, a COPY command could be
interpreted as going in the wrong direction :-(. The risk would be
completely intolerable if any of these commands were allowed in stored
rules, since the rule parsetree would outlive any one compilation of the
backend. Currently that's not true, but they might be allowed sometime.
Barring strenuous objections from someplace, I plan to change these node
types to use booleans or special-purpose enum fields as appropriate.
That will make their representation independent of what the parser token
set happens to be on any given day. We should avoid re-introducing such
dependencies in future.
Comments?
regards, tom lane