Re: Updates of SE-PostgreSQL 8.4devel patches

Robert Haas wrote:
>>> You mean her data just disappears?  Doesn't sound very reasonable to me.
>> In reference cases, we can consider she looks the tables via something
>> like VIEWs implicitly. The "VIEW" can hide several tuple, but it does
>> not break any reference consistency in the raw level.
> 
> I don't understand what this means.
> 
> Suppose we have two tables:

Sorry for lack of explanation.
The idea is similar to several commercial databases with row-level security,
like the Oracle Label Security.

> CREATE TABLE parent (a integer, primary key (a));
> CREATE TABLE child (a integer references parent, b integer);
> 
> Consider these queries:
> 
> 1. SELECT * FROM child
> 2. SELECT * FROM child JOIN parent ON child.a = parent.a

As an image, the above queries are implicitly translated as follows:

1'. SELECT * FROM child             WHERE i_can_see_tuple(child.security_attribute);
2'. SELECT * FROM child JOIN parent             ON child.a = parent.a                AND
i_can_see_tuple(child.security_attribute)               AND i_can_see_tuple(parent.security_attribute);
 

(*) Please note that rewriting WHERE clause for security purpose is    patented, so SE-PostgreSQL changed its
implementationbefore.    It put a hook on ExecScan() to check visibility of fetched tuple.
 

> In query (1), I wouldn't expect the foreign key on child to matter at
> all.  In query (2), of course, the tuples in parent are no longer
> visible, so I expect things to get filtered.  I'm not sure whether
> this is what you're proposing or not.

Yes, it is correct.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>