src/functions/catalog_functions.rs backs the regclass cast with a DefaultHasher-based OID, so:
SELECT 'users'::regclass;
returns a value that matches nothing in pg_class.oid, which since #87 uses the canonical 3-character-prefix formula shared by the views and every persisted catalog OID. Any query that casts to regclass and then joins on the result gets zero rows.
Unlike the other non-canonical producers, the right fix here is probably not to swap in generate_table_oid. regclass in PostgreSQL resolves a name against the catalog — it should look the relation up in pg_class and return its actual oid, which is correct by construction and survives any future change to the OID formula. That needs a little design, hence a separate issue from the collision work.
Also: DefaultHasher is not guaranteed stable across Rust releases, so this OID can change on a rebuild even with no code change.
src/functions/catalog_functions.rsbacks theregclasscast with aDefaultHasher-based OID, so:returns a value that matches nothing in
pg_class.oid, which since #87 uses the canonical 3-character-prefix formula shared by the views and every persisted catalog OID. Any query that casts toregclassand then joins on the result gets zero rows.Unlike the other non-canonical producers, the right fix here is probably not to swap in
generate_table_oid.regclassin PostgreSQL resolves a name against the catalog — it should look the relation up inpg_classand return its actualoid, which is correct by construction and survives any future change to the OID formula. That needs a little design, hence a separate issue from the collision work.Also:
DefaultHasheris not guaranteed stable across Rust releases, so this OID can change on a rebuild even with no code change.