Skip to content

Add extension object coverage check #21

@jnasbyupgrade

Description

@jnasbyupgrade

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).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions