| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Bruce Momjian <bruce(at)momjian(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Josh Berkus <josh(at)agliodbs(dot)com>, Joshua Brindle <method(at)manicmethod(dot)com>, PG Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: How to get SE-PostgreSQL acceptable |
| Date: | 2009-01-31 16:42:17 |
| Message-ID: | 603c8f070901310842w746277iff2dcfd364bdfc70@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
>> 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.
I think the column in pg_attribute and pg_class can and should be an
OID. The issue is whether it's a regular OID column or a new system
column. Stephen and I are saying it should be a regular column.
pg_security can stick around to map OIDs to text labels.
...Robert
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Grzegorz Jaskiewicz | 2009-01-31 16:46:26 | adding stuff to parser, question |
| Previous Message | Andrew Dunstan | 2009-01-31 16:27:35 | Re: mingw check hung |