> Could we instead insist on a unique name per-table, and make this
table's
> key be (conrelid, conname)? Assigning a number seems quite
artificial.
The only problem with this is that I don't want the rename of a
constraint to have to fall over into the pg_depend table. pg_depend
is currently happy with system OIDS or a Relation OID and some unique
number to represent it -- much as pg_description wouldn't want to know
the name of the constraint for the ability to add a comment to it.
> consrc/conbin seem to only cover the check-constraint case. Need
some
> thought about what to store for foreign keys (ideally, enough info
for
> pg_dump to reconstruct the REFERENCES spec without looking at the
> triggers) and unique/primary keys (a link to the implementing index
> seems like a good idea here).
I will implement the various flags required for these. conupdtyp,
condeltyp (on update type and on delete type respectively) as well as
immediate and deferrable bools.
> > I'm not exactly sure how to find out what columns a check
constraint
> > depends on, but I'm sure I'll figure that out sooner or later.
>
> pull_var_clause() on the nodetree representation is your friend.
Thanks for the tip.
> I see a difficulty in the above representation though: what if a
check
> constraint refers to > INDEX_MAX_KEY columns? Maybe conkey had
better
> be an int2[] variable-length array.
Good point.