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

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

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Bernd Helmle <mailings(at)oopsware(dot)de>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, 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:29:23
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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.


In response to


pgsql-hackers by date

Next:From: KaiGai KoheiDate: 2010-01-24 03:40:37
Subject: Re: restructuring "alter table" privilege checks
Previous:From: Robert HaasDate: 2010-01-24 03:16:26
Subject: Re: restructuring "alter table" privilege checks

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