Background
We want a sanity-check that ensures every object owned by the extension is at least mentioned somewhere in a test. This came up because Agent 2's audit found several objects with zero test mentions:
cat_tools.pg_class_v, cat_tools.column (view), cat_tools.pg_all_foreign_keys — not referenced in any test file
cat_tools.get_serial_sequence — zero mentions
_cat_tools._pg_sv_column_array, _cat_tools._pg_sv_table_accessible, catalog_metadata — no direct tests
Approaches considered
pg_depend + pg_read_file (pgTAP test)
Enumerate extension-owned objects via pg_depend, load all test file contents into a temp table via pg_read_file(), assert each object name appears as a substring. Fully specified and self-contained as a pgTAP test, but fragile: depends on superuser filesystem access and a resolvable path to the test files at runtime.
Makefile check-coverage target (shell grep)
Extract object names from sql/cat_tools.sql.in with awk, grep test/sql/*.sql for each name, report misses. Build-time, no database needed. But the awk extraction wasn't fully worked out — the extension uses __cat_tools.create_function() dynamic dispatch for most functions, so naive CREATE FUNCTION pattern matching would miss most of the public API.
Both approaches share the same fundamental weakness
String presence in a comment, a \set line, or a format-string description satisfies the check but proves nothing about actual behavioral coverage. permissions.sql already dynamically enumerates and permission-tests every cat_tools function and type — those would all "pass" a name-mention check without any functional test.
Conclusion
Neither approach gives real confidence. To know whether a function is actually exercised by the test suite requires a proper code coverage tool (e.g., tracking which SQL functions are called during make installcheck). PostgreSQL doesn't have built-in coverage instrumentation for SQL functions, so this would likely require something external.
In the meantime, the more useful work is writing the missing functional tests for the objects identified above, particularly the views (pg_all_foreign_keys, pg_class_v, cat_tools.column).
Background
We want a sanity-check that ensures every object owned by the extension is at least mentioned somewhere in a test. This came up because Agent 2's audit found several objects with zero test mentions:
cat_tools.pg_class_v,cat_tools.column(view),cat_tools.pg_all_foreign_keys— not referenced in any test filecat_tools.get_serial_sequence— zero mentions_cat_tools._pg_sv_column_array,_cat_tools._pg_sv_table_accessible,catalog_metadata— no direct testsApproaches considered
pg_depend + pg_read_file (pgTAP test)
Enumerate extension-owned objects via
pg_depend, load all test file contents into a temp table viapg_read_file(), assert each object name appears as a substring. Fully specified and self-contained as a pgTAP test, but fragile: depends on superuser filesystem access and a resolvable path to the test files at runtime.Makefile
check-coveragetarget (shell grep)Extract object names from
sql/cat_tools.sql.inwith awk, greptest/sql/*.sqlfor each name, report misses. Build-time, no database needed. But the awk extraction wasn't fully worked out — the extension uses__cat_tools.create_function()dynamic dispatch for most functions, so naiveCREATE FUNCTIONpattern matching would miss most of the public API.Both approaches share the same fundamental weakness
String presence in a comment, a
\setline, or a format-string description satisfies the check but proves nothing about actual behavioral coverage.permissions.sqlalready dynamically enumerates and permission-tests everycat_toolsfunction and type — those would all "pass" a name-mention check without any functional test.Conclusion
Neither approach gives real confidence. To know whether a function is actually exercised by the test suite requires a proper code coverage tool (e.g., tracking which SQL functions are called during
make installcheck). PostgreSQL doesn't have built-in coverage instrumentation for SQL functions, so this would likely require something external.In the meantime, the more useful work is writing the missing functional tests for the objects identified above, particularly the views (
pg_all_foreign_keys,pg_class_v,cat_tools.column).