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

2010/1/3 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> (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?

That sounds about right to me, though that function doesn't exist yet. :-)

...Robert