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

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

From: Thom Brown <thombrown(at)gmail(dot)com>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [BUG?] strange behavior in ALTER TABLE ... RENAME TO on inherited columns
Date: 2009-11-04 13:48:10
Message-ID: bddc86150911040548l1c62962dv8bb33ea19f8a0fbd@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
2009/11/4 Alvaro Herrera <alvherre(at)commandprompt(dot)com>:
> KaiGai Kohei wrote:
>
>>   postgres=# SELECT * FROM t2;
>>   ERROR:  could not find inherited attribute "b" of relation "t3"
>>
>> Because t3.b is also inherited from the t2, but ALTER TABLE does not
>> care about multiple inherited columns well.
>>
>> I think we should not allow to rename a column with attinhcount > 1.
>
> I think we should fix ALTER TABLE to cope with multiple inheritance.
>

I'd be interested to see how this should work.  Given KaiGai's
example, how would that be resolved?  That column would already be
merged for the inheriting table, so would renaming it somehow unmerge
it?  Given an insertion into t3 would propagate to both column b's in
table t1 and t2, and then renaming b in t1 wouldn't make sense.  Or
would renaming it be prevented due to dependants?  Or should t3's
inheritance of t1 and t2 implicitly bind t1's and t2's column b to one
another so that one affects the other? (i.e. renaming column b in t1
would also rename column b in t2, or both would require renaming
during the same transaction.)

...or something less confusing. :)

Thom

In response to

Responses

pgsql-hackers by date

Next:From: Peter EisentrautDate: 2009-11-04 14:02:08
Subject: PL/Python array support
Previous:From: Emmanuel CecchetDate: 2009-11-04 13:41:35
Subject: Re: DISTINCT ON

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