On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Joshua Brindle <method@manicmethod.com> writes:
>> Tom Lane wrote:
>>> Right, which is why it's bad for something like a foreign key constraint
>>> to expose the fact that the row does exist after all.
>
>> Once again, this is not an issue for us.
>
> Yes it is an issue; claiming it isn't doesn't make it so. You just
> stated, in effect, that you don't implement data hiding in the
> filesystem because it would break standard Unix filesystem semantics.
> How is that consistent with your opinion that it's okay to break
> standard SQL semantics in order to implement data hiding in a database?
I think you're being pedantic. There are different levels of breakage
and it is a matter of finding one that produces an acceptable
cost-benefit trade-off.
ISTM that we have plenty of evidence on these threads that other
databases do things in a way that is similar to what SE-PostgreSQL is
proposing to do. If people are using the feature in Oracle and
getting value out of it, why should it suddenly become useless when
ported to PostgreSQL?
BTW, Oracle also has join removal, which proves that it isn't
impossible for a high-quality database product to support both
features.
...Robert
