Skip site navigation (1) Skip section navigation (2)

Re: [RFC] Security label support

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [RFC] Security label support
Date: 2010-05-27 20:01:54
Message-ID: 7086.1274990514@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
>> I'm not real sure that you want a dependency for a security label anyway
>> --- wouldn't that mean each label could only be used for one object?

> Err, your question comes across to me like "if you added comments to
> pg_depend, you'd only be able to use a given comment X for one object?".
> Doesn't make alot of sense. :)

Well, one of us is confused.  I thought the idea was that the same
security label would apply to many different objects.  If each object
has its own label, you're going to need an awfully large label cache
for performance to be sane.

> The structure for pg_seclabel we were talking about would be very
> similar to pg_description, eg:

> CREATE TABLE pg_seclabel (
>   objoid oid not null,
>   classoid oid not null,
>   objsubid integer not null,
>   label text 
> );

> We could move label into another table (eg: pg_labels) and then give an
> OID to each label and then store the label's OID in pg_seclabel.

OK, but the notion that you would try to remove "orphan" pg_labels
entries seems entirely wrongheaded to me.  The labels would be
long-lived objects.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Pavel StehuleDate: 2010-05-27 20:02:13
Subject: Re: functional call named notation clashes with SQL feature
Previous:From: Kevin GrittnerDate: 2010-05-27 20:01:09
Subject: Re: Idea for getting rid of VACUUM FREEZE on cold pages

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group