Constraint stuff

I think my last message to Tom (and the list)
about the foreign key stuff and oids ended up
in /dev/null due to a problem on the local
mailer.

Tom had suggested storing a more
understandable form of the foreign key constraint
to make dumping more reasonable in its own table.
I'd guess like the src stored for check constraints.
However, I noticed a few problems with this and
while thinking about it I had a few germs of
ideas which aren't any kind of proposal yet, but
I thought someone might be interested in them.

The problem with storing source is that it doesn't
get changed when things change. Try altering
a column name that has a check constraint, then
dump the database. I don't think this is the
responsibility of the dumper. If we store source
we should be guaranteeing it's correct.
Plus, right now for FK constraints we do something
specific to keep track of the other table referenced
so we can remove the constraints if the table goes
away. But, what happens when we allow subqueries
in check constraints, etc...

So, what I was thinking is, that if we have another
table to store this kind of constraint info, it
should probably store information for all constraints.
I was thinking two tables, one (say pg_constraint)
which stores basic information about the constraint
(what type, the constraint name, primarily constraintd
table, maybe owner if constraints have owners in SQL)
and a source form (see more below).
The second table stores references from this constraint.
So any table, column, index, etc is stored here.
Probably something of the form constraintoid,
type of thing being referenced (the oid of the table?),
the oid of the referenced thing and a number.

The number comes in to the source form thats stored.
Anywhere that we're referencing something that a name
is insufficient for (like a column name or table name)
we put something into the source for that says
referncing column n of the referenced thing m.

Then we create something like
format_constraint(constraintoid) which gives out
an SQL compliant version of the cconstraint.

And it means that if we deleted something, we know fairly
easily whether or not it is being referenced by some
constraint somewhere without writing separate code for
fk constraints and check constraints, etc.. And
renaming wouldn't be a problem.

- There are some problems I see right off both conceptually
and implementation, but I thought someone might be able
to come up with a better idea once it was presented (even
if it's just a "not worth the effort" :) )

One of the problems I see is that if taken to its end,
would you store function oids here? If so, that might
make it harder to allow a drop function/create function
to ever work transparently in the future.
Plus, I'm not even really sure if it would be reasonable
to get a source form like I was thinking of for check
constraints really.