test(pg_catalog): failing OID-stability regressions for #389 / #390

[sunng87]

What

A test-only change that adds failing regression tests reproducing the pg_catalog OID instability described in #389 (and the related #390). No production code is changed.

The intent is to provide a concrete, runnable reproduction that can be used to validate fix candidates — in particular PR #391.

Why these tests

Pooled PostgreSQL clients (DBeaver, JDBC drivers, …) resolve an OID on one connection and reference it on another via joins such as pg_class WHERE relnamespace = <oid>. Those OIDs must therefore be:

1. stable across catalog-table queries within a session (a schema's OID must not change just because another catalog table was queried), and
2. join-consistent (pg_class.relnamespace must equal the pg_namespace.oid a client resolved earlier).

Additionally, the static catalog rows this crate ships reference the canonical pg_catalog namespace OID 11 (e.g. pg_type.typnamespace = 11, pg_proc.pronamespace = 11), so pg_catalog must keep that fixed OID.

The tests (all currently fail on master)

Test	Reproduces	Fails on master with
schema_oid_is_stable_across_pg_attribute_query	#389 — OID drift after pg_attribute evicts the shared OID cache	16385 != 16457
pg_class_resolves_table_via_namespace_oid	#389 — the DBeaver symptom (WHERE relnamespace = <oid> matches nothing)	got 0
pg_catalog_namespace_keeps_fixed_oid_eleven	#390 — pg_catalog must keep OID 11	16385 != 11

Root cause being captured

The dynamic catalog tables (pg_namespace, pg_class, pg_attribute, pg_database) share one OID counter + cache, but each builder rewrites that cache differently. Notably pg_attribute does *oid_cache = swap_cache with table-only keys, evicting every Catalog/Schema OID; the next pg_namespace/pg_class query then re-assigns the schema a different OID via the counter, so an OID a client resolved earlier no longer matches.

Verification

# master (this PR) -> tests FAIL (bug reproduced)
cargo test -p datafusion-pg-catalog --lib oid

# with PR #391 applied on top -> tests PASS (fix confirmed)

I confirmed all three tests fail on master and pass once #391 is applied. cargo fmt --check and cargo clippy --all-features -- -D warnings are clean, so the only CI signal here is the intended cargo test failure.

Notes

• This is a failing-test-first change; CI's Test job will be red on purpose. It's meant to be merged together with (or used to gate) a fix such as fix(pg_catalog): deterministic, stable OIDs for pooled clients (#389, #390) #391, not on its own.
• Includes the pg_catalog namespace should have the fixed OID 11 (static rows use typnamespace=11) #390 test because fix(pg_catalog): deterministic, stable OIDs for pooled clients (#389, #390) #391 addresses both pg_catalog OIDs are assigned per-connection and unstable — breaks pooled clients (DBeaver, etc.) #389 and pg_catalog namespace should have the fixed OID 11 (static rows use typnamespace=11) #390 in the same function; happy to drop it if you'd rather keep this scoped to pg_catalog OIDs are assigned per-connection and unstable — breaks pooled clients (DBeaver, etc.) #389 only.

Refs #389, #390, #391.