Here is morning now, so I started to follow the discussion now... Stephen Frost wrote: > * Gregory Stark (st...@enterprisedb.com) wrote: >> It does seem weird to simply omit records rather than throw an error and >> require the user to use a where clause, even if it's something like WHERE >> pg_accessible(tab).
It was an implementation of very earlier version of SE-PostgreSQL. (Maybe, its revision number was still less than 500.) It rewrites WHERE clause of given queries, but Tom suggested such a query rewrite easily makes a bug and hard to maintain in the future, so I removed the code and put a hook in ExecScan(), which featch a tuple from relation and checks condition. (I think it was a good suggestion. It also enables to reduce the scale of SE-PostgreSQL patches.) Indeed, it requires additional checks and disables a few kind of optimization, when these enhanced-security features are activated. However, I made clear some times that we assume security focused users don't give their first priority on performance. I can understand performance is a significant factor for database management system, so the default of these features are *disabled* unless user explicitly activate them. > It is weird from an SQL perspective, I agree with you there. On the > other hand, it's what the security community is looking for, and is > what's implemented by other databases (Oracle, SQL Server...) that > do row-level security and security labels. Requiring a where clause > or you throw an error would certainly make porting applications that > depend on that mechanism somewhat difficult, and doesn't really seem > like it'd gain you all that much... -- OSS Platform Development Division, NEC KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers