On Tue, Nov 07, 2006 at 11:05:38AM -0500, Jerry Sievers wrote: > Admins; this is (I assume) a not uncommon scenario). > > Suppose you are managing a BIG ugly DB that's in 24x7 production and > desperately in need of constraints of all types. > > (Of course, you inherited this piece of crap and the irresponsible > designers are long gone :-) > > You have verified that the application now honors the new constraints > because on your R&D DBs, the constraints are in place and no > constraint violations are occuring. > > You can't however get business to sign off on proper constraint > addition via ALTER TABLE because the tables are huge and this locks > out concurrent activity for several hours. > > My question; > > Have any of you setup the constraints by doing manual catalog updates > and later (or maybe never), gone back and cleaned up the > non-conforming data using small batch updates or deletes? > > Frobing of pg_constraint and pg_depend (at least) would be required. > > I'm wondering what non-obvious pitfalls exist here? > > Comments? Use the source, luke! Hmmm... interesting problem. For some constraints, I think you could probably handle things pretty well once we have non-blocking index creation (did that get into 8.2?). I guess the real key there would be if the constraint creation code will use indexes when checking the constraints. This would be especially useful for generic CHECK constraints... if you build an index that has a WHERE clause that matches the proposed constraint, the backend could just look to see if there are any entries in the index. If there aren't, you're good to go. In the meantime, I suggest using triggers to enforce your constraints, since you can create one without verifying the underlying data. -- Jim Nasby jim@xxxxxxxxx EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
