Print GRANT clauses in the order the parser reads them - #2415
Print GRANT clauses in the order the parser reads them#2415LucaCappelletti94 wants to merge 1 commit into
GRANT clauses in the order the parser reads them#2415Conversation
ting-hong-shieh
left a comment
There was a problem hiding this comment.
Verified against main at 30d0836b. Feeding main's own output back into main's parser fails:
input: GRANT OWNERSHIP ON ALL TABLES IN SCHEMA s TO ROLE r WITH GRANT OPTION COPY CURRENT GRANTS
main: GRANT OWNERSHIP ON ALL TABLES IN SCHEMA s TO ROLE r COPY CURRENT GRANTS WITH GRANT OPTION
reparse: Expected: end of statement, found: WITH at Line: 1, Column: 73
With this PR the statement round-trips unchanged.
The comment says the clauses are printed in the order the parser reads them, and after the swap that holds for all four trailing clauses, not only the pair being moved. On main, parse_grant reads WITH GRANT OPTION (src/parser/mod.rs:17723), CURRENT GRANTS (17726), AS (17734), GRANTED BY (17740) — exactly the new Display order. A test carrying all four would lock that property rather than just the pair:
verified_stmt(
"GRANT OWNERSHIP ON ALL TABLES IN SCHEMA s TO ROLE r WITH GRANT OPTION COPY CURRENT GRANTS AS g GRANTED BY b",
);I added that assertion to parse_grant on this branch and it passes across all dialects; on main the same statement prints COPY CURRENT GRANTS WITH GRANT OPTION AS g GRANTED BY b.
cargo test --all-features at 2ee726d3: 1584 passed, 0 failed. cargo fmt --all -- --check and cargo clippy --all-targets --all-features -- -D warnings both clean.
Display for
GrantprintedCURRENT GRANTSbeforeWITH GRANT OPTION, butparse_grant readsthem the other way round. For a statement carrying both, the printer therefore produced text the parser rejects.Swapping the two blocks in the printer fixes it.