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>
