"Robert Haas" <robertmhaas@gmail.com> writes:
>> This is just a different syntax for KaiGai's label storage
>> implementation. It doesn't really answer any of the hard questions,
>> like what the heck is the behavior of foreign keys.
> What do you find inadequate about KaiGai's answers to those hard questions?
Mainly just that they're only one set of possible answers. If we're
thinking of baking a particular set of semantics into SQL syntax,
we'd better be darn sure that they are the right semantics --- both
in terms of widest usefulness, and in terms of not being stuck behind
the eight-ball if the SQL standards committee ever moves to standardize
a similar behavior.
Another point is that the proposed behavior leaks quite a lot of
information, since it will fail operations on the basis of tuples that
supposedly aren't visible to the invoking user. While I admit that it's
hard to see an alternative if we're to preserve FK integrity, I have to
worry that this definition isn't going to satisfy the tin-foil-hat
brigade that are supposed to be the main users of SEPostgres. If the
goal is "you don't know the row is there", this doesn't seem to meet it.
I wonder whether it wouldn't make more sense to pursue restrictions
at some different level. SQL already has the concept of REFERENCE
permission, ie, not just anybody can make a foreign key reference to
your table. Maybe there has to be a rule that you can't make an FK
reference to a table you don't have full read permissions for. The
restrictions in the other direction (what can PK table's owner find out
about FK table's contents) are pretty interesting too.
regards, tom lane
