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 <[EMAIL PROTECTED]>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
