Tom Lane wrote:
>"Oliver Elphick" <olly(at)lfix(dot)co(dot)uk> writes:
>> (Mind you, I think I have not yet got a reliable way of finding the
>> ultimate ancestor of an inherited constraint. Is it actually possible to
>> do this with queries or do we have to add a boolean flag to pg_relcheck
>> to be set where the constraint is/is not inherited?)
>In fact, I was about to 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
[... 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's constraints, and omit
>from the child any constraints that have the same rcname AND the same
>rcsrc as a constraint of the parent. (You need not look at anything
>other than the immediate parent, because constraints inherited from
>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 was actually written
>with a redundant constraint:
>since it cannot tell that childx's constraint wasn't simply inherited.
>However, it's not clear to me that suppression of redundant constraints
>is a bad thing ;-)
It seems to be quite reasonable to drop them.
Oliver Elphick Oliver(dot)Elphick(at)lfix(dot)co(dot)uk
Isle of Wight http://www.lfix.co.uk/oliver
PGP key from public servers; key ID 32B8FAA1
"Jesus saith unto him, I am the way, the truth, and the
life; no man cometh unto the Father, but by me."
pgsql-hackers by date
|Next:||From: The Hermit Hacker||Date: 1998-11-24 17:29:36|
|Subject: Re: [HACKERS] 6.4.1 schedule (was segfault with -z option)|
|Previous:||From: Tom Lane||Date: 1998-11-24 17:21:48|
|Subject: Re: [HACKERS] pg_dump - segfault with -z option |