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.
...Robert
