Re: tracking inherited columns (was: patch for check constraints using multiple inheritance)

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Yeb Havinga <yebhavinga(at)gmail(dot)com> writes:
>> The root cause seems to center around multiple inheritance of the same
>> column without a common ancestor. Another way to approach the problem, is to
>> prevent the user to create a setup, i.e. when adding a column to B that
>> already exists in A, or when adding a inheritance relation A-C or B-c, if A
>> and B share column names. He could then get a hint he should add a common
>> ancestor with that column. This preemptively prevents problems with renames
>> and other changes.

> It also breaks compatibility with previous releases for no particular
> reason.

Well, if it were only a hint, and thus didn't actually "prevent"
anything, then it wouldn't be breaking compatibility. But I don't
like the idea much either. It would be extremely expensive, if not
impossible, to determine whether all parents having the similarly-named
column got it from the same common ancestor. (In particular, if the
user had previously ignored the hint, you could have situations where
there isn't a unique ancestor that the column can be traced to; then
what do you do?)

I think we'd be putting huge amounts of effort into a case that no more
than one or two people would ever hit.

regards, tom lane