Robert Haas <robertmh...@gmail.com> writes:
> On Tue, Oct 5, 2010 at 12:27 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> That doesn't make permissions on them useless, so you're attacking a
>> straw man.
> Really? I'm confused. What is the use case for the status quo?
Access to tables that you have no direct privileges on, mainly.
(This is significantly more useful when you consider updates on
views than when you consider selects alone.) Even if it were totally
useless from the point of view you're choosing to adopt, you'd have
a hard row to hoe to convince us to take out a SQL-standard feature.
The SQL facility *is* leak-proof AFAICS for column filtering.
Row filtering, not so much. We could make it leak-proof (by making
the view into a hard optimization boundary) but I think everyone's
agreed that the performance consequences would be so bad as to make
such a feature useless. Unfortunately I don't see any design that
avoids the performance penalty while still being guaranteed
leak-proof. Once you realize that performance itself can be a leak
channel, it may well be that that's simply a contradiction in terms.
And I don't see a lot of use in plugging some side channels while
others remain open. At least, not without a much more explicit
threat model than anyone's actually offered for this patch, which
would explain exactly why we need to close these particular side
channels and not others.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
