dump takes some extension objects

[xpusostomos]

We are using the extension pg_stat_statements. This extension creates various objects in your schema, like a function called pg_stat_statements and a view called pg_stat_statements.

pgschema dumps the view, but not the function which causes it to fail. (That in itself is odd, is it getting confused between the view and the function and dumping only one?) In any case, it shouldn't dump either one. There is way to interrogate the pg catalog to find out which objects are owned by an extension. something like when pg_depend.deptype = 'e'. Those objects should be left alone.

[christophostertag]

We also encountered this with PostGIS, including an unwanted migration-plan consequence rather than only dump output.

In a disposable synthetic test using pgschema 1.13.0, PostgreSQL 18.4 and PostGIS 3.6.3, both the target and external planning database already had PostGIS installed in public. The desired application schema only added this function:

CREATE FUNCTION public.f() RETURNS integer LANGUAGE sql AS $$ SELECT 3 $$;

Without member-specific ignore rules, the generated plan included these exact statements before the function:

REVOKE SELECT ON TABLE spatial_ref_sys FROM PUBLIC;
REVOKE SELECT ON TABLE geography_columns FROM PUBLIC;
REVOKE SELECT ON TABLE geometry_columns FROM PUBLIC;
DROP VIEW IF EXISTS geometry_columns CASCADE;
DROP VIEW IF EXISTS geography_columns CASCADE;
DROP TABLE IF EXISTS spatial_ref_sys CASCADE;
DROP TYPE IF EXISTS geometry_dump RESTRICT;
DROP TYPE IF EXISTS valid_detail RESTRICT;

Applying this plan in the disposable test failed with:

ERROR: cannot drop view geometry_columns because extension postgis requires it (SQLSTATE 2BP01)

PostgreSQL rejected the drop; we are not reporting a successful deletion. Planning alone is enough to observe the unwanted operations.

We verified that these are extension members through pg_depend / pg_extension. The workaround was to exclude the five objects, consistently for both plan and dump/export:

[tables]
patterns = ["spatial_ref_sys"]

[views]
patterns = ["geometry_columns", "geography_columns"]

[types]
patterns = ["geometry_dump", "valid_detail"]

Our intended behavior is that preinstalled extensions keep owning their objects and privileges, while pgschema continues to manage application tables, spatial columns and indexes that use those extensions. This is separate from managing CREATE EXTENSION or installing extensions in the planning database.

I would like to contribute a focused fix that makes extension-member filtering consistent, with regressions for both this PostGIS case and your pg_stat_statements case. Would that scope be welcome, and are there compatibility expectations around explicitly managing extension-member privileges that the patch should preserve? I will keep the contribution limited to this issue and verify it against current upstream code before submitting.

The observations above are from the recorded v1.13.0 run; they are not a claim that current main has already been retested.