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 implementation before.
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(at)ak(dot)jp(dot)nec(dot)com>