fix: skip privileges for ignored objects in .pgschemaignore (#392)

[tianzhou]

Summary

• When objects (functions, tables, etc.) are ignored via .pgschemaignore patterns, their GRANT/REVOKE privilege statements now are also excluded from dump and plan output
• Added ShouldIgnorePrivilegeByObjectType() to check object names against type-specific ignore patterns
• Added filtering in buildPrivileges(), buildRevokedDefaultPrivileges(), and buildColumnPrivileges() in the inspector

Fixes #392

Test plan

• Added TestIgnorePrivilegesForIgnoredObjects integration test reproducing the exact issue scenario (dblink extension functions with revoked PUBLIC EXECUTE)
• Existing TestIgnoreIntegration and TestIgnorePrivileges tests pass (no regressions)
• Run: go test -v ./cmd -run TestIgnorePrivilegesForIgnoredObjects

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR filters out privileges for objects that are ignored via .pgschemaignore by adding ShouldIgnorePrivilegeByObjectType and calling it in the three privilege-building paths of the inspector. The approach is correct in structure, but there is a P1 mismatch for function/procedure types: the privilege query stores the full signature (dblink_connect_u(text)) as objectName, while ShouldIgnoreFunction always receives the bare name — so an exact-name ignore pattern silently fails to suppress the corresponding privilege, even though the function itself is correctly ignored.

Confidence Score: 4/5

Safe to merge with caution — the fix works for wildcard patterns (the documented use case) but has a P1 gap for exact function name patterns.

One P1 logic bug: exact-name ignore patterns for functions/procedures fail to suppress their corresponding privileges because the privilege query includes the full argument signature while the ignore check uses the bare name. The issue is masked by the test only exercising wildcard patterns. A secondary P2 involves TABLE/VIEW cross-pattern contamination and silently-swallowed cleanup errors in the test.

ir/ignore.go — ShouldIgnorePrivilegeByObjectType needs to strip the argument list for FUNCTION/PROCEDURE before pattern matching, and should check only the type-matching pattern list for TABLE vs VIEW.

Vulnerabilities

No security concerns identified. The change only affects which privilege statements are emitted during dump/plan; it does not modify how privileges are applied or verified against the database.

Important Files Changed

Filename	Overview
ir/ignore.go	Adds ShouldIgnorePrivilegeByObjectType; has two issues: function/procedure names include full signature in privilege queries so exact-name patterns silently fail, and TABLE/VIEW check each other's pattern lists causing cross-type contamination.
ir/inspector.go	Adds three ignore checks in buildPrivileges, buildRevokedDefaultPrivileges, and buildColumnPrivileges — integration is correct; correctness depends on the ignore logic in ignore.go.
cmd/ignore_integration_test.go	New TestIgnorePrivilegesForIgnoredObjects covers the reported issue but only exercises wildcard patterns, missing the exact-name case that exposes the signature-mismatch bug; cleanup targets wrong PG instance.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[buildPrivileges / buildRevokedDefaultPrivileges / buildColumnPrivileges] --> B{ignoreConfig set?}
    B -- No --> C[Include privilege in output]
    B -- Yes --> D[ShouldIgnorePrivilegeByObjectType]
    D --> E{objectType}
    E -- TABLE/VIEW --> F[Check c.Tables AND c.Views]
    E -- FUNCTION --> G[Check c.Functions with FULL signature]
    E -- PROCEDURE --> H[Check c.Procedures with FULL signature]
    E -- SEQUENCE --> I[Check c.Sequences]
    E -- TYPE --> J[Check c.Types]
    G --> K{Pattern match}
    K -- Wildcard pattern --> L[Matches correctly]
    K -- Exact name pattern --> M[Fails: bare name does not match name with args]
    L --> N[Skip privilege]
    M --> C
    F --> O{match?}
    O -- Yes --> N
    O -- No --> C

Loading

_{Reviews (1): Last reviewed commit: "fix: skip privileges for ignored objects..." | Re-trigger Greptile}

[Copilot]

Pull request overview

This PR extends .pgschemaignore behavior so that when schema objects are ignored (tables, functions, etc.), related privilege output (GRANT/REVOKE, revoked default privileges, and column privileges) is also suppressed, addressing issue #392 around extension-installed functions.

Changes:

• Added ShouldIgnorePrivilegeByObjectType() to map privilege object types to the relevant ignore sections.
• Filtered ignored-object privileges in the inspector’s explicit privileges, revoked default privileges, and column privileges builders.
• Added an integration test covering ignored functions/tables and their associated privileges in both dump and plan.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 5 comments.

File	Description
ir/inspector.go	Skips privilege rows when the underlying object is ignored (explicit, revoked defaults, column privileges).
ir/ignore.go	Introduces type-aware privilege ignore helper to reuse object ignore patterns for privilege filtering.
cmd/ignore_integration_test.go	Adds an integration test reproducing #392 and validating dump/plan output excludes privileges for ignored objects.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

In buildColumnPrivileges, ignored-object filtering checks both ShouldIgnoreTable(tableName) and ShouldIgnoreView(tableName), but the underlying query (GetColumnPrivilegesForSchema) only returns table_name without relkind/object_type. This means a non-ignored table can have its column privileges dropped just because its name matches a [views] pattern (and vice-versa), which is different from the more precise type-based filtering used for non-column privileges.

Consider extending the column privileges query to also return relation kind / object_type (e.g., TABLE vs VIEW for relkind 'r' vs 'v'/'m'), then reuse ShouldIgnorePrivilegeByObjectType for accurate filtering.

[tianzhou]

Tables and views share the same namespace in PostgreSQL — you can't have a table and a view with the same name in the same schema. So a name matching both [tables] and [views] patterns would refer to the same relation regardless of its kind. No cross-contamination is possible in practice.