Technical Analysis: Adding TAP Tests for contrib/oid2name

Core Problem

The contrib/oid2name utility in PostgreSQL is a command-line tool that resolves OIDs (Object Identifiers) to human-readable names and vice versa. It can list databases, tablespaces, tables, indexes, and sequences along with their OIDs and associated filenode numbers. Despite being a shipping contrib module, oid2name lacks automated test coverage via PostgreSQL's TAP testing framework.

This is an infrastructure/quality gap rather than a functional bug. Without tests:

• Regressions in oid2name behavior can slip through undetected during refactoring
• Changes to catalog queries or output formatting have no safety net
• The tool's behavior against real clusters isn't validated in CI

Proposed Solution

The patch introduces TAP tests (t/*.pl files) for oid2name that:

1. Test database listing — verifying oid2name can enumerate databases with correct OID mappings
2. Test tablespace listing — ensuring tablespace enumeration works correctly
3. Test system object listing — covering system catalog object resolution
4. Test tables with indexes and sequences — validating that related objects (indexes, sequences associated with tables) are properly listed

The tests run against an actual PostgreSQL cluster (as TAP tests do via PostgreSQL::Test::Cluster), which means they exercise the real code path including libpq connections, catalog queries, and output formatting.

Architectural Context

Why TAP Tests (vs. Regression Tests)

oid2name is a client-side binary utility, not a SQL-level feature. PostgreSQL's TAP framework (prove-based Perl tests) is the standard mechanism for testing command-line tools like pg_dump, pg_basebackup, pg_amcheck, etc. This is the correct testing approach for this type of contrib module.

Testing Challenges for oid2name

Testing oid2name has inherent challenges:

• OIDs are non-deterministic — OIDs assigned to user-created objects vary between runs, so tests must either create objects and then verify the mapping round-trips correctly, or test against well-known system objects with fixed OIDs
• Output format parsing — The tool produces tabular text output that tests must parse
• Cluster state dependency — Results depend on what objects exist in the test cluster

The approach of testing against "an actual cluster" (as stated by the author) suggests the tests create a fresh cluster, populate it with known objects, and then verify oid2name output against expected results.

Design Considerations

This is a straightforward test-addition patch with relatively low controversy potential. Key review considerations would include:

1. Test robustness — Are tests resilient to OID variability and platform differences?
2. Test isolation — Do tests properly create/clean up their test objects?
3. Coverage completeness — Does the test suite exercise all major oid2name flags (-d, -t, -i, -s, -x, -q, etc.)?
4. Consistency with other contrib TAP tests — Does the test style match patterns used in pg_amcheck, pg_checksums, etc.?

Current Status

This is an initial submission (v1) with no reviewer responses yet. The patch is likely to receive attention from committers who focus on test infrastructure and contrib module maintenance. As a pure test-addition patch with no behavioral changes to production code, the barrier to commit is relatively low — primarily requiring verification that tests are well-written, stable, and provide meaningful coverage.

Impact Assessment

• Risk: Very low — adds only test code, no production code changes
• Value: Moderate — improves CI coverage for a utility that has historically been under-tested
• Maintenance burden: Low — TAP tests for stable utilities rarely need updates unless the tool's interface changes