Re: 8.4 release planning

Here is morning now, so I started to follow the discussion now...

Stephen Frost wrote:
> * Gregory Stark (stark(at)enterprisedb(dot)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 <kaigai(at)ak(dot)jp(dot)nec(dot)com>