Re: ADD/DROP constraints

From: "Zeugswetter Andreas DCP SD" <ZeugswetterA(at)spardat(dot)at>
To: "Greg Stark" <gsstark(at)mit(dot)edu>, <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: ADD/DROP constraints
Date: 2006-06-09 08:29:56
Message-ID: E1539E0ED7043848906A8FF995BDA5790116B90B@m0143.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas DCP SD 2006-06-09 08:35:58 Re: ADD/DROP constraints
Previous Message Nis Jorgensen 2006-06-09 08:12:21 Re: Fabian Pascal and RDBMS deficiencies in fully implementing