Jaime Casanova wrote:
> On Wed, Dec 24, 2008 at 6:50 AM, KaiGai Kohei <kaigai@kaigai.gr.jp> wrote:
>> 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.
>>
>
> but you still can do it, right?
> there are any other advantages, like something you can't do now?
Yes, we still can see "relkind" via system cache.
When we fetch a tuple from pg_attribute, it need to look up the
RELOID system cache to get the relkind of its relation.
The reason why I considered the change is preferable is advantanges
in performance and robustness in security design.
The first one is obvious. If we have "attkind" member, it is not
necessary to look up the RELOID system cache for each tuples.
The other need an explanation. A database superuser is allowed
to update system catalog by hand, if it is allowed by the security
policy. For example, he will be able to update "relkind" in some
of pg_class, even if it never happen in general DDLs.
If a "relkind" is changed from 'r' to 'c', we deal pg_attribute
entries pointing the tuple as db_tuple class, not db_column class,
because they are not already columns.
It means we fundamentally have to check permissions on pg_attribute
when pg_class is updated, or pg_attribute should have its identifier
information. I think the later approach is more simple.
Please consider an another instance. In filesystem, 'x' permission
bit has different meaning between files and directries. If a derectory
without no child files is handled as a regular file suddenly, it can
make a confusion. It is a similar situation.
So, I want to put a needed attribute to identify itself.
Thanks,
> if not, i think you need to probe that there will be any benefit in
> speed and that is significant otherwise this seems like premature
> optimization and that AFAIR is the root of all evil :)
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>
