> > 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.
