Robert Haas wrote:
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.
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 <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
