Re: ADD/DROP constraints - Mailing list pgsql-hackers

From Zeugswetter Andreas DCP SD
Subject Re: ADD/DROP constraints
Date
Msg-id E1539E0ED7043848906A8FF995BDA5790116B90B@m0143.s-mxs.net
Whole thread Raw
In response to ADD/DROP constraints  (Greg Stark <gsstark@mit.edu>)
List 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 by date:

Previous
From: "Zeugswetter Andreas DCP SD"
Date:
Subject: Re: Ending EXPLAIN ANALYZE early (was Re: That EXPLAIN ANALYZE patch still needs work)
Next
From: "Zeugswetter Andreas DCP SD"
Date:
Subject: Re: ADD/DROP constraints