feat: add column_grant_overridden_by_table_grant lint (0033)

[mattmuller]

What kind of change does this PR introduce?

New WARN-level lint 0033_column_grant_overridden_by_table_grant.

What is the current behavior?

Nothing flags a column-level privilege that is made pointless by a table-level privilege. Postgres allows an operation if the role holds the privilege on the table or on the column. A table-level SELECT covers every column, so GRANT SELECT (a, b) ON t TO anon does not restrict anon to a and b if anon also holds SELECT on t. The author thinks a column is hidden, and it is not.

On Supabase the table-level grant often comes from the default grants on public tables, or from PUBLIC.

What is the new behavior?

The lint reports (table, role, privilege) where the role is anon or authenticated, has an entry for the privilege in pg_attribute.attacl (SELECT, INSERT, UPDATE, REFERENCES), and has_table_privilege(role, table, privilege) is true. The latter includes PUBLIC and role inheritance. Tables must be in an exposed schema (pgrst.db_schemas, default public). Extension-owned tables are skipped.

What the catalogue can and cannot show. A plain REVOKE SELECT (col) ON t FROM role against a table-level grant stores nothing, because there is nothing to remove, so that case cannot be detected and is not attempted. The lint only reports the detectable footprint: a column entry that exists alongside the table grant. Docs state this limitation.

Minimal repro:

create table public.profiles(id int primary key, display_name text, email text);
grant select on public.profiles to anon;
grant select (id, display_name) on public.profiles to anon;
-- anon can still select email

select * from lint."0033_column_grant_overridden_by_table_grant";

Remediation (documented): revoke the table-level privilege, then grant the columns again, since a table-level revoke also clears the role's column entries of that kind.

Additional context

Related but different: #196 / #197 cover a policy whose role lacks a table privilege. #197 also claims number 0031, so numbers in this series may need adjusting at merge.

How it was tested

test/sql/0033_column_grant_overridden_by_table_grant.sql. The fixtures grant SELECT on new public tables to PUBLIC, so the test revokes everything first.

• Not flagged: column-level SELECT with no table-level grant; table-level SELECT with no column entries; table-level SELECT with column-level UPDATE (different privileges).
• Flagged: table-level and column-level SELECT on the same role; table-level SELECT inherited from PUBLIC with a column grant to anon.
• Resolution: dropping the table-level grant returns 0 rows.

Full suite passes on supabase/postgres 15.14.1.169 and 17.6.1.169, including the splinter.sql validity check. bin/check_lints.py passes.

False-positive risk. Low to moderate. The column grant is always redundant when it fires. It may be a leftover from an earlier setup where the table grant is intentional.