Robert Haas wrote:
> On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> * KaiGai Kohei (kaigai@kaigai.gr.jp) wrote:
>>> Stephen Frost wrote:
>>>> I think Bruce's question was where you stored the security_acl and
>>>> security_label columns. Based on your response (and a bit of purusal
>>>> through the code.google site), it looks like you still have security_acl
>>>> and security_label defined as internal columns and being included
>>>> for at least system tables (or is it everywhere?).
>>> In the current working tree, it (security id) is stored within
>>> padding field of HeapTupleHeader, so internal facility can read
>>> it via HeapTupleGetSecLabel(), but I already removed "security_acl"
>>> and "security_label" definition.
>>> Its basic structure is unchanged, the text form of security label
>>> is stored within pg_security system catalog.
>> I'm pretty sure that structure is part of what people were unhappy about
>> though, and what makes it a much more invasive change that violates
>> certain levels in the system by requiring information at much lower
>> levels than it had before.
>
> IANAC, but that's my impression too. The simplified patch shouldn't
> assume that row-level security in its current form is going to end up
> getting put back in. AFAICS, there's no reason why the security ID
> for tables can't be a regular attribute in pg_class, or why the
> security attribute for columns can't be a regular attribute in
> pg_attribute.
If it is "identifier", it can be compoundable.
I dislike it is held as "text". It fundamentaly breaks SE-PostgreSQL's
architecture, and requires to scrap near future.
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
