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)kaigai(dot)gr(dot)jp>
Cc: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Bernd Helmle <mailings(at)oopsware(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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-27 21:58:35
Message-ID: 603c8f071001271358j61b12e0ajd7c15d606614608d@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Jan 27, 2010 at 3:42 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jan 27, 2010 at 10:17 AM, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>> (2010/01/27 23:29), Robert Haas wrote:
>>>
>>> 2010/1/27 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)com>:
>>>>
>>>> The attached patch is revised one based on the V3 approach.
>>>> The only difference from V3 is that it also applies checks on the
>>>> AT_AlterColumnType option, not only renameatt().
>>>
>>> I think I was clear about what the next step was for this patch in my
>>> previous email, but let me try again.
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg02407.php
>>>
>>> See also Tom's comments here:
>>>
>>> http://archives.postgresql.org/pgsql-hackers/2010-01/msg00110.php
>>>
>>> I don't believe that either Tom or I are prepared to commit a patch
>>> based on this approach, at least not unless someone makes an attempt
>>> to do it the other way and finds an even more serious problem.  If
>>> you're not interested in rewriting the patch along the lines Tom
>>> suggested, then we should just mark this as Returned with Feedback and
>>> move on.
>>
>> The V3/V5 patch was the rewritten one based on the Tom's comment, as is.
>> It counts the expected inhcount at the first find_all_inheritors() time
>> at once, and it compares the pg_attribute.attinhcount.
>> (In actually, find_all_inheritors() does not have a capability to count
>> the number of merged from a common origin, so I newly defined the
>> find_all_inheritors_with_inhcount().)
>>
>> Am I missing something?
>
> Err... I'm not sure.  I thought I understood what the different
> versions of this patch were doing, but apparently I'm all confused.
> I'll take another look at this.

OK, I took a look at this. It's busted:

test=# create table top (a integer);
CREATE TABLE
test=# create table upper1 () inherits (top);
CREATE TABLE
test=# create table upper2 () inherits (top);
CREATE TABLE
test=# create table lower1 () inherits (upper1, upper2);
NOTICE: merging multiple inherited definitions of column "a"
CREATE TABLE
test=# create table lower2 () inherits (upper1, upper2);
NOTICE: merging multiple inherited definitions of column "a"
CREATE TABLE
test=# create table spoiler (a integer);
CREATE TABLE
test=# create table bottom () inherits (lower1, lower2, spoiler);
NOTICE: merging multiple inherited definitions of column "a"
NOTICE: merging multiple inherited definitions of column "a"
CREATE TABLE
test=# alter table top rename a to b;
ALTER TABLE
test=# select * from spoiler;
ERROR: could not find inherited attribute "a" of relation "bottom"

Also, there is a compiler warning due to an unused variable that
should be fixed.

I'll mark this Waiting on Author.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2010-01-27 22:09:14 Re: Review: listagg aggregate
Previous Message David E. Wheeler 2010-01-27 21:56:22 Re: Add on_perl_init and proper destruction to plperl [PATCH]