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

On Sat, Jan 23, 2010 at 1:45 PM, Bernd Helmle <mailings@oopsware.de> wrote:
> --On 14. Januar 2010 16:04:17 +0900 KaiGai Kohei <kaigai@ak.jp.nec.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.

...Robert