Tom Lane wrote:
> KaiGai Kohei <kaigai@kaigai.gr.jp> writes:
>>>> There are also
>>>> some interesting questions about SQL spec compliance and whether a
>>>> database that silently hides some rows from you will give semantically
>>>> consistent results.
>>> Yeah -- that's a potentially serious issue; KaiGai, have you looked into
>>> it?
>
>> Yes, I consider the policy to filter any violated tuple looks consistently.
>> The policy enforces any tuple has to be filtered before using them, and
>> it helps that computational processes don't get any effect from them.
>
>> But proving innocence is generally hard task.
>> At first, I want to know what points are you worried about the most.
>
> Unique constraints and foreign-key constraints seem the most pressing
> problems. What will you do to avoid having different viewers have
> different opinions about whether a constraint is violated?
The behavior of unique constraints are kept as is. Thus, a client with
some hidden tuples may not be able to insert a new tuple, though the tuple
seems to him containing unique values.
From strict security viewpoint, this behavior has a possibility to leak the
existence of hidden tuples to clients without enough permissions.
To resolve them, polyinstantiation table support will be required ultimately.
When a client tries to insert a new tuple into a table in which foreign-key
constraints are configured, the foreign-key values have to be included in his
scope. If not so, the current transaction will be aborted.
If the constraint has CASCADE rule, all the foreign-keys have to be updated
when the value of primary key is changed. It is an exception for the policy
to filter. If the client have any violated tuple, whole the process will be
aborted. In normal cases, those tuples are merely excluded from the target of
updating, although.
As the conclusion, we intend to keep the consistency of any constrains.
But some issues are remained from strict security viewpoint.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>
