Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Date
Msg-id 4B4173F9.2030604@ak.jp.nec.com
Whole thread Raw
In response to Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
List 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 by date:

Previous
From: Jaime Casanova
Date:
Subject: Re: patch - per-tablespace random_page_cost/seq_page_cost
Next
From: Simon Riggs
Date:
Subject: Re: New VACUUM FULL