Re: pg_constraint
От | Rod Taylor |
---|---|
Тема | Re: pg_constraint |
Дата | |
Msg-id | 1c6201c1ed32$e1d86ed0$ad02000a@jester обсуждение исходный текст |
Ответ на | pg_constraint ("Rod Taylor" <rbt@zort.ca>) |
Ответы |
Re: pg_constraint
|
Список | pgsql-hackers |
> 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.
В списке pgsql-hackers по дате отправления: