While working on some code today, I noticed that RELKIND_UNCATALOGED appears to serve no useful purpose. In the few places where we check for it at all, we treat it in exactly the same way as RELKIND_RELATION. It seems that it's only purpose is to serve as a placeholder inside each newly-created relcache entry until the real relkind is filled in. But this seems pretty silly, because RelationBuildLocalRelation(), where the relcache entry is created, is called in only one place, heap_create(), which already knows the relkind. So, essentially, right now, we're relying on the callers of heap_create() to pass in a relkind and then, after heap_create() returns, stick that same relkind into the relcache entry before inserting the pg_class tuple. The only place where that doesn't happen is in the bootstrap code, which instead allows RELKIND_UNCATALOGED to stick around in the relcache entry even though we have RELKIND_RELATION in the pg_class tuple. But we don't actually rely on that for anything, so it seems this is just an unnecessary complication.
The attached patch cleans it up by removing RELKIND_UNCATALOGED and teaching RelationBuildLocalRelation() to set the relkind itself. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
remove-relkind-uncataloged.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
