On May29, 2012, at 16:13 , Kohei KaiGai wrote: > 2012/5/29 Florian Pflug <f...@phlo.org>: >> My motivation for suggesting that flag was to prevent people who want RLS, >> yet aren't concerned about leaks, from having to pay the performance penalty >> associated with not pushing down predicates. >> > I think it is a reasonable selection. For example, it make sense in case when > users obviously don't have privilege to create a function and don't care about > estimation of invisible values using iteration of proving. > The owner is the only person who can determine whether it is harmless, or not.
Nice to know that we're on the same page here. >> Noah's comments, however, made me realize that whether one cares about >> potential leaks is usually not a per-table property, but rather a property >> of the user executing the query. Some users (like the middle-ware that sits >> on top of your database) you might trust to not exploit leaks, while wanting >> the tightest security possible for others. Which made me suggest a per-role >> flag which essentially overrides the security barrier stuff. Explaining that >> behaviour as "behave as if all functions are LEAKPROOF" might haven been a >> tad confusion, though. Maybe a better explanation is "behave as if no >> sub-query has the security barrier flag set", or even "don't let security >> concerns prevent predicate push-down". >> > Hmm... It might make sense to allow table-owner to set up suitable grade > between security and performance. However, isn't it a feature to be > discussed in the 2nd commit-fest? I think we can construct this type of > adjustment on the basis of minimum functionality. Agreed. If the flag is per-role, not per-policy, the feature is orthogonal to the whole RLS feature. So yeah, let's postpone it to a later date. best regards, Florian Pflug -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
