Tom Lane <t...@sss.pgh.pa.us> writes: > Robert Haas <robertmh...@gmail.com> writes: >>> Yeah, people like certification, but they also like products that work. >>> Did you stop reading before getting to my non-security-based complaints? > >> I read them, but I suspect they are issues that can be addressed. How >> would any of this affect join removal, anyway? > > It would prevent us from making optimizations that assume foreign key > constraints hold; which is a performance issue not a covert-channel > issue.
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). I wonder if we need a special kind of relational integrity trigger which requires that the privileges on a source row be a superset of the privileges on the target row. Can you even test "superset" on these privileges? Or are they too general for that? And would you have trouble adjusting the privileges later because giving someone access to a label would require checking every row to see if they have access to every referenced row too? -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's 24x7 Postgres support! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
