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

(2010/01/04 4:06), Robert Haas wrote:
> On Jan 3, 2010, at 12:31 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> In practice the reasonable engineering alternatives may just be to do
>> what KaiGai's patch does, or to do nothing. In that case I think a good
>> argument can be made for the latter. Nobody has ever complained about
>> this from the field AFAIR; but we might get complaints if we disable
>> cases that used to work fine.
>
> Maybe. The current behavior of allowing the rename but then breaking
> queries certainly isn't awesome. I think if someone is willing to
> implement a more careful check we should accept it.

The condition to prevent problematic renaming might be modified to handle
diamond inheritances correctly.

The current patch raises an error when pg_attribute.inhcount > 1.
But, in actually, it should raise an error when the number of origins
of the attribute to be renamed is larger than 1.
It shall be match with the inhcount unless it does not have diamond
inheritances.

We can easily check the number of origins with walking on the pg_inherits
catalog. So, it seems to me the condition should be rewritten like:

BEFORE:
if (attform->attinhcount > 1)
ereport(ERROR, ...);

AFTER:
if (number_of_attribute_origin(myrelid, oldattname) > 1)
ereport(ERROR, ...);

Am I missing something?

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>