On Tue, Jan 27, 2009 at 2:18 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Joshua Brindle <met...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers