Re: tracking inherited columns (was: patch for check constraints using multiple inheritance)
| От | Tom Lane |
|---|---|
| Тема | Re: tracking inherited columns (was: patch for check constraints using multiple inheritance) |
| Дата | |
| Msg-id | 540.1281016763@sss.pgh.pa.us обсуждение |
| Ответ на | Re: tracking inherited columns (was: patch for check constraints using multiple inheritance) (Robert Haas <robertmhaas@gmail.com>) |
| Ответы |
Re: tracking inherited columns (was: patch for check
constraints using multiple inheritance)
|
| Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes:
> Yeb Havinga <yebhavinga@gmail.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
В списке pgsql-hackers по дате отправления: