Re: [PATCH] Add reloption for views to enable RLS
| От | walther@technowledgy.de |
|---|---|
| Тема | Re: [PATCH] Add reloption for views to enable RLS |
| Дата | |
| Msg-id | 38a0981d-50a4-f16e-bb7f-32b6a1303249@technowledgy.de обсуждение исходный текст |
| Ответ на | Re: [PATCH] Add reloption for views to enable RLS (Christoph Heiss <christoph.heiss@cybertec.at>) |
| Ответы |
Re: [PATCH] Add reloption for views to enable RLS
|
| Список | pgsql-hackers |
Christoph Heiss: >> xxx_owner=true would be the default and xxx_owner=false could be set >> explicitly to get the behavior we are looking for in this patch? > > I'm not sure if an option which is on by default would be best, IMHO. I > would rather have an off-by-default option, so that you explicitly have > to turn *on* that behavior rather than turning *off* the current. Just out of curiosity I asked myself whether there were any other boolean options that default to true in postgres - and there are plenty. ./configure options, client connection settings, server config options, etc - but also some SQL statements: - CREATE USER defaults to LOGIN - CREATE ROLE defaults to INHERIT - CREATE COLLATION defaults to DETERMINISTIC=true There's even reloptions, that do, e.g. vacuum_truncate. > My best suggestions is maybe something like run_as_invoker=t|f, but that > would probably raise the same "invoker vs definer" association. It is slightly better, I agree. But, yes, that same association is raised easily. The more I think about it, the more it becomes clear that really the current default behavior of "running the query as the view owner" is the special thing here, not the behavior you are introducing. If we were to start from scratch, it would be pretty obvious - to me - that run_as_owner=false would be the default, and the run_as_owner=true would need to be turned on explicitly. I'm thinking about "run_as_owner" as the better design and "defaults to true" as a backwards compatibility thing. But yeah, it would be good to hear other opinions on that, too. Best Wolfgang
В списке pgsql-hackers по дате отправления: