Re: tracking inherited columns (was: patch for check constraints using multiple inheritance)
От | Yeb Havinga |
---|---|
Тема | Re: tracking inherited columns (was: patch for check constraints using multiple inheritance) |
Дата | |
Msg-id | 4C5A8F2B.4000504@gmail.com обсуждение исходный текст |
Ответ на | Re: tracking inherited columns (was: patch for check constraints using multiple inheritance) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: tracking inherited columns (was: patch for check
constraints using multiple inheritance)
|
Список | pgsql-hackers |
Tom Lane wrote: > Yeb Havinga <yebhavinga@gmail.com> writes: > >> A.a_column B.a_column >> | / >> v v >> C.a_column >> >> C inherits from A and B. >> > > Well, if A and B inherited the column from a common ancestor, he can > easily do that. If not, maybe he should have thought harder before he > started. I do NOT agree that issuing a rename against C is a sane way > of dealing with this. > Ok, I understand the intuition behind not wanting this kind of update. 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. /me ducks regards, Yeb Havinga
В списке pgsql-hackers по дате отправления: