[shehjaddev]

Fixes #638

Column privileges of several types on the same columns were rendered as GRANT INSERT, UPDATE (a, b) .... PostgreSQL attaches a column list only to the privilege right before it, so that grants INSERT on the whole table.

The column list is now attached to every privilege, e.g. GRANT INSERT (a, b), UPDATE (a, b) ON TABLE t TO app;. This applies to GRANT, REVOKE, REVOKE GRANT OPTION FOR and WITH GRANT OPTION statements, in both plan and dump (both use the same generator).

Added testdata/diff/privilege/issue_638_multi_privilege_column_grant, covering narrowing a multi-privilege column grant (revoke + grant) and adding privileges to an existing column grant. It fails without the fix.

[greptile-apps]

Confidence Score: 4/5

[Medium impact] Changes how column-level database privileges are rendered in SQL.

The PR appears safe to merge, with a non-blocking gap in grant-option test coverage.

Findings

1.  Grant-option changes lack tests ▶

Summary

Attaches the column list to every privilege in column-level GRANT and REVOKE statements.

• Each column privilege now keeps its own column list.

_{Reviews (1) · Last reviewed commit: "fix: render per-privilege column lists i..." · Reviewed by Greptile}

[greptile-apps]

Grant-option changes lack tests

The new regression covers creating, dropping, and adding column privileges, but not the changed grant-option branches. Existing grant-option fixtures use table privileges, so they would not catch a regression in these column-specific statements. Add cases with multiple privileges on the same columns that add and remove WITH GRANT OPTION.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!