> > For tracking of Foreign Keys, Check constraints, and maybe NULL / NOT > > NULL (specific type of check constraint) I intend to create (as per > > suggestion) pg_constraint. > > Hmmm...I don't see the need at all for NOT NULL constraint tracking. The > spec doesn't seem to require it and we do not have names for them anyway. > Even if they were given names, it'd be pointless, as there's only one per > column.
Correct me if I'm wrong, but aren't NOT NULL constraints a shortform of the similar CHECK constraint (according to spec which I don't have infront of me). I've been debating combining the 2 and allowing names on them, but won't do this yet. CHECK (VALUE NOT NULL) would mark the pg_attribute column and assign the name. > Primary keys and unique keys are SQL constraints - are you going to bother > tracking them as well or leave them in the current format? Maybe you could > do it with a view or something. > Why not just create a pg_references table and leave pg_relcheck as is? relcheck needs changes anyway. It needs to track the specific columns that it depends on, rather than simply the table. This is for reasons of DROP COLUMN. Last thing you want is a bad check constraint after that ;) The other reason is that they're supposed to be in the same namespace (which makes sense) and having each constraint in its own table would be silly. Of note, the above table should also have immediate, and deferrable bools attached to it. I debated about the primary / unique keys, but indicies seem to do a good enough job with those. ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
