2012/6/4 Florian Pflug <fgp@phlo.org>:
> On Jun4, 2012, at 17:38 , Kohei KaiGai wrote:
>> I'm worry about future maintenance issues, once we have
>> RLSBYPASS permission or something user visible…
>
> I fear that without a generic way to disable RLS regardless which
> RLS policy function is in effect, we're creating a huge maintenance
> issue for DBAs. In a lot of shops, the DBA is responsible for a large
> number of databases, each potentially using a completely different
> approach to RLS and hence a completely different policy function.
>
Here is two problems around RLSBYPASS. The first is we have
no idea to handle invalidation of prepared-statement when current
user is switched, right now. The second is we can have another
way to describe same RLS policy without PG original enhancement
towards permission mechanism...
> Without something like RLSBYPASS, the DBA needs to have intimate
> knowledge about the different RLS policies to e.g. guarantee that his
> backups aren't missing crucial information, or that the replication
> system indeed replicates all rows.
>
> With RLSBYPASS, all he needs to do is grant one privilege to his
> replication or backup user. The rest can be left to the development
> or support team for a specific application.
>
It seems to me you can define a function which implements site-
specific security requirement (E.g "backup should not be prevented
by RLS policy"), then include it as a part of RLS policy
(or implicitly added by extensions, like sepgsql tries to do).
These are the reason why I hesitate to go ahead with RLSBYPASS
permission.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>