Re: Table constraint ordering disrupted by pg_dump

At 17:51 3/04/01 -0400, Tom Lane wrote:
>
>Rather than using "c.rcname = pg_relcheck.rcname" as part of the match
>condition, consider
> (c.rcname = pg_relcheck.rcname OR
> (c.rcname[0] = '$' AND pg_relcheck.rcname[0] = '$'))
>so that any two nameless constraints will be considered duplicate if
>their rcsrcs match.

Looks reasonable, but users can define constraints with names starting with
'$', so there is a small chance we will discard a redundant constraint,
which is probably OK.

BTW, it looks like 'ALTER TABLE ADD CONSTRAINT' on a parent does not affect
the already created children. Is this intended behaviour? It seems like a
but and it certainly will cause an issue for pg_dump.

>PS: Philip, it seems to me that lines 2071-2121 in pg_dump.c are largely
>a waste of time, since the subsequent query to fetch the constraints
>will do all the same work over again. Just have to relax the check at
>line 2157 to allow ntups2 <= ncheck, and update ncheck after that.

I was planning to clean up that area when 7.1 was out the door since I
assumed that there was an obscure reason for it's existence.

Looking at the code more closely, I think it is part of the sanity check
pg_dump tries to do. The first piece of SQL finds inherited constraints,
and the second one finds non-inherited constraints, but the way the SQL is
structured, I can't really see how they would fail to come to the correct
total, so it's value as a sanity check seems minimal. Do you agree, or
should I leave it in?

----------------------------------------------------------------
Philip Warner | __---_____
Albatross Consulting Pty. Ltd. |----/ - \
(A.B.N. 75 008 659 498) | /(@) ______---_
Tel: (+61) 0500 83 82 81 | _________ \
Fax: (+61) 0500 83 82 82 | ___________ |
Http://www.rhyme.com.au | / \|
| --________--
PGP key available upon request, | /
and from pgp5.ai.mit.edu:11371 |/