Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns

Поиск
Список
Период
Сортировка
От KaiGai Kohei
Тема Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Дата
Msg-id 4B4173F9.2030604@ak.jp.nec.com
обсуждение исходный текст
Ответ на Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Список pgsql-hackers
(2010/01/04 13:18), Tom Lane wrote:
> Robert Haas<robertmhaas@gmail.com>  writes:
>> 2010/1/3 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>>> �if (number_of_attribute_origin(myrelid, oldattname)>  1)
>>> � � �ereport(ERROR, ...);
>>>
>>> Am I missing something?
>
>> That sounds about right to me,
>
> It looks remarkably inefficient to me.  Do you propose to search the
> entire database's inheritance tree to derive that number?  And do it
> over again at each child table?

Yes,

> The method I suggested would allow the
> necessary information to be extracted during the initial search for
> child tables, which we have to do anyway.

find_all_inheritors() returns a clean list which does not contain
duplicated OID of the inherited relation, so it seems to me we need
to change the function prototype but it affects other parts, or to add
a new function which also returns number of duplications, not only OIDs.

Or, we can call find_inheritance_children() in renameatt() as if
find_all_inheritors() doing except for list_concat_unique_oid().

What is the most preferable?
I don't have any preference in the way to fix the problem.

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jaime Casanova
Дата:
Сообщение: Re: patch - per-tablespace random_page_cost/seq_page_cost
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: New VACUUM FULL