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)  (Robert Haas <robertmhaas@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: documentation for committing with git
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: Review of Synchronous Replication patches