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

From: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Bernd Helmle <mailings(at)oopsware(dot)de>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-24 03:48:35
Message-ID: 4B5BC313.8020301@kaigai.gr.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(2010/01/24 12:29), Robert Haas wrote:
> On Sat, Jan 23, 2010 at 1:45 PM, Bernd Helmle<mailings(at)oopsware(dot)de> wrote:
>> --On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>
>> wrote:
>>> This patch adds:
>>>
>>> List *find_column_origin(Oid relOid, const char *colName)
>>>
>>> It returns the list of relation OIDs which originally defines the given
>>> column. In most cases, it returns a list with an element. But, if the
>>> column is inherited from multiple parent relations and merged during the
>>> inheritance tree, the returned list contains multiple OIDs.
>>> In this case, we have to forbid changing type and renaming to keep
>>> correctness of the table definition.
>>
>> Here's a slightly edited version of this patch from reviewing, fixing the
>> following:
>>
>> * Fix a compiler warning by passing a pointer to skey to
>> systable_beginscan() (it's an array already)
>>
>> * Edit some comments
>>
>> The patch works as expected (at least, i don't see any remaining issues).
>> I'm going to mark this ready for committer.
>
> I don't think this is ready for committer, becauseTom previously
> objected to the approach taken by this patch here, and no one has
> answered his objections:
>
> http://archives.postgresql.org/pgsql-hackers/2010-01/msg00144.php
>
> I think someone needs to figure out what the worst-case scenario for
> this is performance-wise and submit a reproducible test case with
> benchmark results. In the meantime, I'm going to set this to Waiting
> on Author.

Basically, I don't think it is not a performance focused command,
because we may be able to assume ALTER TABLE RENAME TO is not much
frequent operations.

However, I'm interested in between two approaches.
I'll check both of them. Isn't is necessary to compare the vanilla code base,
because the matter is a bug to be fixed?

http://archives.postgresql.org/message-id/4B41BB04.2070609@ak.jp.nec.com
http://archives.postgresql.org/message-id/A7739F610FB0BD89E310D85E@[172.26.14.62]

Please wait for weekday, because I don't have physical (not virtual) machine
in my home.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jaime Casanova 2010-01-24 05:06:38 Re: further explain changes
Previous Message KaiGai Kohei 2010-01-24 03:40:37 Re: restructuring "alter table" privilege checks