fix(pg_catalog): deterministic, stable OIDs for pooled clients (#389, #390)

[kadosh1000]

What

Makes pg_catalog OID assignment deterministic and stable, fixing two problems that break pooled PostgreSQL clients (e.g. DBeaver) against a datafusion-postgres server.

Closes #389 — OIDs unstable across connections.
Closes #390 — pg_catalog namespace should be the fixed OID 11.

Problem

PgCatalogSchemaProvider assigns catalog/schema/table OIDs from a per-provider AtomicU32 counter, incremented in iteration order. A typical pgwire server creates a fresh SessionContext + setup_pg_catalog per connection, so the same object gets a different OID on different connections. Pooled clients resolve an OID on one connection and reference it on another, so pg_class WHERE relnamespace = <oid> matches nothing and no tables are listed.

Separately, pg_catalog receives a generated OID, but the static catalog rows this crate ships reference the canonical PG_CATALOG_NAMESPACE OID 11 (pg_type.typnamespace = 11, pg_proc.pronamespace = 11, …). No namespace with OID 11 exists in pg_namespace, so joins from a system object to its namespace fail — e.g. DBeaver can't resolve any column's data type (every column shows as unknown).

Fix

Add stable_oid(&OidCacheKey): a deterministic hash (DefaultHasher — fixed keys, so stable across processes) of the object's (catalog, schema, table) name, mapped into the positive int4 range [16384, i32::MAX], with pg_catalog pinned to its fixed OID 11. The seven counter sites in pg_class/pg_namespace/pg_database/pg_attribute now call stable_oid instead of oid_counter.fetch_add.

The same object now resolves to the same OID on every connection, independent of iteration order or which catalog table is queried first.

Notes

• Left the now-unused oid_counter field/params in place to keep the diff minimal — happy to remove them (and the Ordering imports) if you'd prefer.
• Collision risk is negligible for realistic catalog sizes; can switch to a wider/interned scheme if desired.
• Verified against a live DBeaver session (tables and column types now resolve) plus unit coverage in a downstream consumer.
• Filed as pg_catalog OIDs are assigned per-connection and unstable — breaks pooled clients (DBeaver, etc.) #389 / pg_catalog namespace should have the fixed OID 11 (static rows use typnamespace=11) #390; addressed together here since the fix is a single function — happy to split into two PRs if you'd rather review them separately.

[sunng87]

@kadosh1000 thanks for the quick fix. please check the lint failure.

[kadosh1000]

@sunng87 no problem :) lint issues fixed

[sunng87]

@kadosh1000 Thank you! I'm trying to fix the same issue with another method that can reuse our oid counter mechanism. The root cause is some valid keys in oid_cache may be accidentally dropped. Let me try if I can get it fixed in that way.

[kadosh1000]

Done in #393 #394

[kadosh1000]

Closing — the maintainer fixed this upstream in #393 (pg_attribute OID eviction) and #394 (pg_catalog pinned to OID 11), released in datafusion-pg-catalog v0.18.2. Verified v0.18.2 resolves the pooled-client (DBeaver) issues on our side. Thanks!