On Sat, Jan 31, 2009 at 8:32 AM, Stephen Frost <sfr...@snowman.net> wrote: > * KaiGai Kohei (kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
