Skip site navigation (1) Skip section navigation (2)

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

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Thom Brown <thombrown(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Date: 2010-01-04 04:52:09
Message-ID: 4B4173F9.2030604@ak.jp.nec.com (view raw or flat)
Thread:
Lists: pgsql-hackers
(2010/01/04 13:18), Tom Lane wrote:
> Robert Haas<robertmhaas(at)gmail(dot)com>  writes:
>> 2010/1/3 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)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(at)ak(dot)jp(dot)nec(dot)com>

In response to

Responses

pgsql-hackers by date

Next:From: Simon RiggsDate: 2010-01-04 08:04:35
Subject: Re: New VACUUM FULL
Previous:From: Jaime CasanovaDate: 2010-01-04 04:42:45
Subject: Re: patch - per-tablespace random_page_cost/seq_page_cost

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group