fix(pg_catalog): stop pg_attribute from evicting schema/catalog OIDs (#389)

[sunng87]

What

A surgical fix for the pg_catalog OID instability in #389: stop pg_attribute from evicting Catalog/Schema OIDs out of the shared OID cache. Plus two regression tests.

This is a narrower, more targeted alternative to #391 (which derives OIDs deterministically via hashing). Both fix the same symptom; this one keeps the existing counter + cache design and just removes the over-broad cache rewrite that caused the drift.

Root cause

The dynamic catalog tables (pg_namespace, pg_class, pg_attribute, pg_database) share one OID counter + cache, and each builder reconciles that cache against the live catalog. pg_attribute reconciled by wholesale-replacing the cache:

let mut swap_cache = HashMap::new();
... swap_cache.insert(Table(..), oid) ...   // only Table keys ever inserted
*oid_cache = swap_cache;                     // cache becomes *exactly* the tables I visited

pg_attribute enumerates only tables, so swap_cache only ever held Table keys. The replacement therefore silently deleted every Catalog/Schema OID — not because those objects were gone, but because pg_attribute never looked at them. The next pg_namespace/pg_class query then hit a cache miss for the schema and re-allocated it a different OID via the counter. A pooled client (DBeaver, JDBC) that resolved a schema OID earlier — e.g. pg_class WHERE relnamespace = <oid> — now matched nothing, so no tables/columns were listed.

Reproduces within a single shared SessionContext (the deployment model of the shipped server, which shares one context across all connections):

pg_namespace.oid(public): 16384 -> 16457   (unstable, after a pg_attribute query)
pg_class rows joining on relnamespace=16384: 0

Key nuance: pg_attribute does preserve OIDs for the tables it visits (it reads oid_cache.get and carries the value into swap_cache). The bug is purely that its wholesale *oid_cache = swap_cache discards the keys it doesn't visit. It conflates "I didn't enumerate it" with "it doesn't exist."

Fix

Reconcile surgically, the way pg_namespace already does — drop only stale Table entries, leave Catalog/Schema entries untouched, then refresh the live table OIDs:

oid_cache.retain(|key, _| match key {
    OidCacheKey::Catalog(..) => true,
    OidCacheKey::Schema(..) => true,
    OidCacheKey::Table(..) => table_oid_cache.contains_key(key),
});
oid_cache.extend(table_oid_cache);

The other three builders don't need changes:

• pg_namespace — already surgical (retain + extend).
• pg_database — already surgical (retain + extend).
• pg_class — wholesale-replaces, but its view is complete (catalog+schema+table), so replace == upsert + correct GC. No drift.

After the fix the schema OID is stable across a pg_attribute query and the join resolves:

pg_namespace.oid(public): 16384 -> 16384   (stable)
pg_class rows joining on relnamespace=16384: 1

Tests

Two regression tests added (both fail on master, pass with this change):

• schema_oid_is_stable_across_pg_attribute_query — a schema's OID must not change after a column-metadata query.
• pg_class_resolves_table_via_namespace_oid — the DBeaver symptom: filtering pg_class by an earlier-resolved relnamespace must still resolve the table.

cargo fmt --check, cargo clippy --all-features -- -D warnings, the full datafusion-pg-catalog suite (48), and the dbeaver/psql/pgcli/metabase integration tests all pass.

Scope

Addresses #389 only. #390 (pg_catalog must keep the fixed namespace OID 11 that the static catalog rows reference) is orthogonal and intentionally left untouched here. (A test for #390 lives on the separate test-only branch/PR #392.)

Closes #389.

vs. #391

#391 replaces the counter entirely with deterministic stable_oid(key) = hash(key). That is the more robust design (also survives process restarts and makes the cache redundant), but it's a larger change and, as written, leaves dead code that fails this repo's -D warnings gate (unused Ordering imports + unread oid_counter fields + a clippy collapsible_if). This PR is the minimal fix that removes the actual drift while preserving the existing design; either approach resolves the symptom.