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 по дате отправления: