Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane <t...@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 <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
