Re: row_security GUC, BYPASSRLS
От | Noah Misch |
---|---|
Тема | Re: row_security GUC, BYPASSRLS |
Дата | |
Msg-id | 20150918060719.GB3682120@tornado.leadboat.com обсуждение исходный текст |
Ответ на | Re: row_security GUC, BYPASSRLS (Adam Brightwell <adam.brightwell@crunchydatasolutions.com>) |
Ответы |
Re: row_security GUC, BYPASSRLS
Re: row_security GUC, BYPASSRLS Re: row_security GUC, BYPASSRLS |
Список | pgsql-hackers |
On Tue, Sep 15, 2015 at 03:18:21PM -0400, Adam Brightwell wrote: > On Tue, Sep 15, 2015 at 2:26 PM, Joe Conway <mail@joeconway.com> wrote: > >> Joe Conway <mail@joeconway.com> writes: > >>> There are use cases where row_security=force will be set in production > >>> environments, not only in testing. > > Noah's suggestion of using a per table attribute > > would work -- in fact I like the idea of that better than using the > > current GUC. > > FWIW, I also concur with a per table attribute for this purpose. In > fact, I think I really like the per-table flexibility over an > 'all-or-nothing' approach better too. Great. Robert, does that work for you, too? If so, this sub-thread is looking at three patches: 1. remove row_security=force 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to policies 3. add DDL-controlled, per-table policy forcing They ought to land in that order. PostgreSQL 9.5 would need at least (1) and (2); would RLS experts find it beneficial for me to take care of those? Thanks, nm
В списке pgsql-hackers по дате отправления: