Re: row_security GUC does not behave as documented
От | Alvaro Herrera |
---|---|
Тема | Re: row_security GUC does not behave as documented |
Дата | |
Msg-id | 20160104033926.GG58441@alvherre.pgsql обсуждение исходный текст |
Ответ на | Re: row_security GUC does not behave as documented (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: row_security GUC does not behave as documented
|
Список | pgsql-hackers |
Tom Lane wrote: > Stephen Frost <sfrost@snowman.net> writes: > > On Sunday, January 3, 2016, Tom Lane <tgl@sss.pgh.pa.us> wrote: > >> The fine manual says that when row_security is set to off, "queries fail > >> which would otherwise apply at least one policy". However, a look at > >> check_enable_rls() says that that is a true statement only when the user > >> is not table owner. If the user *is* table owner, turning off > >> row_security seems to amount to just silently disabling RLS, even for > >> tables with FORCE ROW LEVEL SECURITY. > >> > >> I am not sure if this is a documentation bug or a code bug, but it > >> sure looks to be one or the other. > > > The original reason for changing how row_security works was to avoid a > > change in behavior based on a GUC changing. As such, I'm thinking that has > > to be a code bug, as otherwise it would be a behavior change due to a GUC > > being changed in the FORCE RLS case for table owners. > > Well, I tried changing the code to act the way I gather it should, and > it breaks a whole bunch of regression test cases. See attached. I think this means we need to postpone 9.5.0 for a week. -- Álvaro Herrera http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: