> btw, there is serious problem with row-level security and constraints. For > example, user with low security level could use unique constraint to know > about existence of a row with higher security. I don't know, what is the > best practice to avoid this. >
It is out of scope for this feature. We usually calls this type of information leakage "covert channel"; that is not avoidable in principle. However, its significance is minor, because attacker must know identical data to be here, or must have proving for each possible values. Its solution is simple. DBA should not use value to be confidential as unique key. If needed, our recommendation is alternative key, instead of natural key, because its value itself does not have worth.
I should add a note of caution onto the documentation according to the previous consensus, however, I noticed it had gone from the sgml files while I was unaware. So, let me add description on the documentation.
