[idea] a copied relkind in pg_attribute

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>

Responses

Browse pgsql-hackers by date

  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)