Re: ADD/DROP constraints
От | Zeugswetter Andreas DCP SD |
---|---|
Тема | Re: ADD/DROP constraints |
Дата | |
Msg-id | E1539E0ED7043848906A8FF995BDA5790116B90B@m0143.s-mxs.net обсуждение исходный текст |
Ответ на | ADD/DROP constraints (Greg Stark <gsstark@mit.edu>) |
Список | pgsql-hackers |
> On a separate note. The one major remaining piece here is in > constraints. I'm thinking what I have to check is that every > constraint present on the parent table is present on the > child tables. And I'm thinking I should do that by looking at > the constraint's textual definition (consrc). > > This doesn't allow you to get by with a single stronger > constraint -- you would still need the redundant looser > constraint to satisfy the inheritance. Yes, I think you would actually want eighter an identical, or a stronger constraint on the child. > But it does let you get by with constraint names that don't > match the parent's. > > I'm not sure that's such a good thing, since pg_dump would > then generate a redundant constraint when it generates the > table. Maybe that would go if constraints got conislocal and coninh. > > Or maybe I should insist that a matching constraint name be > present *and* that the source text match? That's more of a > pain to code though. I think in the meantime, I would check that eighter a source match is present OR a constraint with the same name. This would allow more flexibility and imho still enough safety checking. Until we have (or feel a need for) check logic for "stronger constraint" it would be the op's responsibility. Andreas
В списке pgsql-hackers по дате отправления: