Tom Lane <tgl@sss.pgh.pa.us> writes:
> Robert Haas <robertmhaas@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!