Tom Lane wrote: >"Oliver Elphick" <olly@lfix.co.uk> writes: >> (Mind you, I think I have not yet got a reliable way of
findingthe >> ultimate ancestor of an inherited constraint. Is it actually possible to >> do this with queries or do
wehave to add a boolean flag to pg_relcheck >> to be set where the constraint is/is not inherited?) > >In fact, I was
aboutto point out that the query you were describing >couldn't possibly give you a reliable answer, quite independent
of>whether the backend is implementing it properly or not.
Yes, I had been using a concrete example; the results were not
sufficiently general.
[... skip example ...]
>It seems to me that the correct way to do this is to compare each of a >table's constraints against its immediate
parent'sconstraints, and omit >from the child any constraints that have the same rcname AND the same >rcsrc as a
constraintof the parent. (You need not look at anything >other than the immediate parent, because constraints
inheritedfrom >more distant ancestors will also be listed for the parent.)
That looks good. I'll see if I can do it that way.
>There is a case that pg_relcheck does not allow you to distinguish, >and that is whether or not the child definition
wasactually written >with a redundant constraint:
[...skip example...]
>since it cannot tell that childx's constraint wasn't simply inherited. >However, it's not clear to me that
suppressionof redundant constraints >is a bad thing ;-)
It seems to be quite reasonable to drop them.
--
Oliver Elphick Oliver.Elphick@lfix.co.uk
Isle of Wight http://www.lfix.co.uk/oliver PGP key from public servers; key
ID32B8FAA1 ======================================== "Jesus saith unto him, I am the way, the truth,
andthe life; no man cometh unto the Father, but by me." John 14:6