| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | pgsql-hackers(at)postgresql(dot)org |
| Subject: | uncataloged tables are a vestigial husk |
| Date: | 2012-06-13 16:36:11 |
| Message-ID: | CA+TgmobKKc7C6zwfvEhYK5f+gWjpty7A8kLmHAe4h-9vDksB_Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| remove-relkind-uncataloged.patch | application/octet-stream | 5.7 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2012-06-13 16:45:34 | Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation. |
| Previous Message | Tom Lane | 2012-06-13 16:27:25 | Re: [COMMITTERS] pgsql: Mark JSON error detail messages for translation. |