> Could we instead insist on a unique name per-table, and make this
> key be (conrelid, conname)? Assigning a number seems quite
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
> thought about what to store for foreign keys (ideally, enough info
> 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
> > 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
> constraint refers to > INDEX_MAX_KEY columns? Maybe conkey had
> be an int2 variable-length array.
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2002-04-26 15:10:18|
|Subject: Re: PSQL \x \l command issues |
|Previous:||From: Tom Lane||Date: 2002-04-26 14:50:32|
|Subject: Re: pg_constraint |