On 10/9/13 1:10 PM, Robert Haas wrote:
On Tue, Sep 24, 2013 at 10:40 PM, Peter Eisentraut <pete...@gmx.net> wrote:
On Tue, 2013-09-24 at 11:58 +0200, Bernd Helmle wrote:
Hmm not sure i understand this argument either: this patch doesn't
allow disabling a primary key. It only supports FKs and CHECK
constraints explicitly.
Well, as soon as the patch for cataloging not-null constraints as check
constraints is available, it will be possible to create views that
depend functionally on check constraints. Then you'll have the same
problem there.
It's also not clear why this patch only supports foreign keys and check
constraints. Maybe that's what was convenient to implement, but it's
not a principled solution to the general issue that constraints can be
involved in dependencies.
I agree with these concerns, as well as those raised by Tom Lane and
Fabien COELHO, and I think they indicate that we shouldn't accept this
patch. So I'm marking this as Rejected.
I see a use case for disabling FKs and CHECKS but not PKs or UNIQUE
constraints: FKs and CHECKS don't depend on additional state information
(namely an index), so it's easy to just disable them temporarily and then
re-enable them. The same isn't true about a PK or UNIQUE constraint.
Of course we could decide to do something more complex to handle disabling PK/UNIQUE...
though at that point it'd be better to just allow temporarily disabling any index. But I
think there's an argument to be made for that being beyond the scope of disabling
"simple" constraints... it's a pretty high bar to set that we won't accept a
patch that disables simple constraints but not those involving indexes.
--
Jim C. Nasby, Data Architect j...@nasby.net
512.569.9461 (cell) http://jim.nasby.net
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
