* Tom Lane (t...@sss.pgh.pa.us) wrote: > Adam Brightwell <adam.brightw...@crunchydatasolutions.com> writes: > > Through this effort, we have concluded that for RLS the case of > > invalidating a plan is only necessary when switching between a superuser > > and a non-superuser. Obviously, re-planning on every role change would be > > too costly, but this approach should help minimize that cost. As well, > > there were not any cases outside of this one that were immediately apparent > > with respect to RLS that would require re-planning on a per userid basis. > > Hm ... I'm not following why we'd need a special case for superusers and > not anyone else? Seems like any useful RLS scheme is going to require > more privilege levels than just superuser and not-superuser.
Just to clarify this- the proposal allows RLS to be implemented
essentially by any user-defined qual, where that qual can include the
current user, the IP the user is connecting from, or more-or-less
anything else, possibly even via a user-defined function or security
module. It is not superuser-or-not. This discussion is about how to
support users for which RLS should not be applied. I can see that being
useful at a more granular level than superuser-or-not, but even at that
level, RLS is still extremely useful.
> Could we put the "if superuser then ok" test into the RLS condition test
> and thereby not need more than one plan at all?
As discussed, that unfortunately doesn't quite work.
This discussion, in general, has been quite useful and I'll work on
adding documentation to the wiki pages which discusses the consideration
and suggestions for a GUC to disable-or-error when RLS is encountered,
along with a per-role capability to bypass RLS; that is in line with the
goal of avoiding adding superuser-specific capabilities.
Thanks,
Stephen
signature.asc
Description: Digital signature
