From: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
---|---|
To: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | [idea] a copied relkind in pg_attribute |
Date: | 2008-12-24 11:50:08 |
Message-ID: | 495221F0.7090101@kaigai.gr.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
It is an idea to improve the implementation of SE-PostgreSQL.
I need a copied relkind in pg_attribute, to help its decision
making.
When we access on pg_attribute via ALTER TABLE or DML statement
directly, SE-PostgreSQL checks privilleges for the fetched tuples.
If the relation pointed by its attrelid has RELKIND_RELATION,
the fetched tuple is a column, so db_column object class should
be applied. Otherwise, db_tuple object class should be applied,
because it is not a column, like an entity of composite type.
The current implementation need to lookup RELOID system cache to
identify the relkind of the relation, because pg_attribtue does
not have any information about "relkind". However, I also think
it is not an ideal implementation, even if its frequency is enough
small.
So, I have a plan to put a new member named as "attkind" into
pg_attribute to hold a copied value of its "relkind".
It enables to identify the attribute without looking up system
cache, so it is better than current one.
The pg_class.relkind is always unchanged, so it does not have
any problematical point.
Please comment anything, if you have alternative idea or opinions.
If reviewer intend to comment about the point, it can be fixed with
the above way.
Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2008-12-24 11:56:31 | Re: Hot standby and b-tree killed items |
Previous Message | Fujii Masao | 2008-12-24 11:22:07 | Re: Archiving control (a part of synch rep patches) |