Re: How to get SE-PostgreSQL acceptable
От | KaiGai Kohei |
---|---|
Тема | Re: How to get SE-PostgreSQL acceptable |
Дата | |
Msg-id | 49850CEB.6030209@kaigai.gr.jp обсуждение исходный текст |
Ответ на | Re: How to get SE-PostgreSQL acceptable (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: How to get SE-PostgreSQL acceptable
Re: How to get SE-PostgreSQL acceptable Re: How to get SE-PostgreSQL acceptable |
Список | pgsql-hackers |
Robert Haas wrote: >>> 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. OK, I accept to omit a facility to save security id on padding field of HeapTupleHeader *in this step*, if is has no other matter unexpected. One melancholic thing is adding a member into pg_proc. It defines more than 2000 of entries which I have to modify correctly. :( Is there any script to help it? Thanks, -- KaiGai Kohei <kaigai@kaigai.gr.jp>
В списке pgsql-hackers по дате отправления: