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: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: 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" <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-04 03:41:49
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
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:
>  if (attform->attinhcount > 1)
>      ereport(ERROR, ...);
>  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.  :-)


In response to


pgsql-hackers by date

Next:From: Tom LaneDate: 2010-01-04 04:12:39
Subject: Re: Buffer statistics for pg_stat_statements
Previous:From: Robert HaasDate: 2010-01-04 03:39:40
Subject: Re: patch - per-tablespace random_page_cost/seq_page_cost

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