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)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: (view raw, whole thread or download thread mbox)
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:
> 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?[]

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

KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>

In response to


pgsql-hackers by date

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

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