Re: 8.4 release planning

On Tue, Jan 27, 2009 at 12:52 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jan 27, 2009 at 11:49 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> It would prevent us from making optimizations that assume foreign key
>>> constraints hold; which is a performance issue not a covert-channel
>>> issue.
>
>> Oh, I see now. That problem is going to be common to row-level DAC
>> and SE-PostgreSQL proper. It would not surprise me if any sort of
>> row-level access control turns out to be bad for performance, but
>> mainly because the overhead of checking permissions on every tuple is
>> bound to cost something.
>
> 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.
> And you won't soothe people by telling them that obsolete versions of
> Postgres would have been that slow all the time.

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.

...Robert