Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> Right, but you expect that to be a small and predictable cost, say in
> >> the single-digits-percentage range. Plan optimizations that
> >> suddenly stop happening can cost you multiple orders of magnitude.
>
> > Well, look at it another way. If we don't accept row-level security
> > into PostgreSQL, then people will have to implement it themselves. In
> > fact, I currently have a real application that does exactly this. The
> > row-filtering is done, in essence, by having the web application add
> > certain conditions to the WHERE clause of certain queries depending on
> > which user is making the request. And if those WHERE clauses happen
> > to mention columns from table X, then table X won't be a candidate for
> > join removal. The only difference is that the logic is in my app
> > rather than in the database itself.
>
> > To put that another way, row-level permissions are just another
> > attribute of a table that could potentially affect the query result,
> > and the impact of referring to that attribute will be exactly the same
> > as the impact of referring to any other attribute in that table.
>
> The flaw in that argument is that as you are doing it, the
> de-optimization only happens on queries that actually need the behavior.
> As the SEPostgres patch is constructed, the planner could *never* trust
> an FK for optimization since it would have no way to know whether row
> level permissions might be present (perhaps only for some rows) at
> execution time. You could only get back the optimization in builds with
> SEPostgres compiled out. That's pretty nasty, especially for packagers
> who have to decide which build setting will displease fewer users.
I am afraid that SQL-level row permissions would also cause that
problem, and I thought they were enabled by default. (The configure
flag --enable-selinux only controls SE-Linux support.)
-- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB
http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
