Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type
Date
Msg-id 12279.1483480004@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. haswrong type  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. haswrong type  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List pgsql-hackers
I wrote:
> Hah:

> regression=# create table p(f1 int);
> CREATE TABLE
> regression=# create table c1(extra smallint) inherits(p);
> CREATE TABLE
> regression=# alter table p add column f2 int;
> ALTER TABLE
> regression=# insert into c1 values(1,2,3);
> INSERT 0 1
> regression=# alter table p alter column f2 type bigint using f2::bigint;
> ERROR:  attribute 2 has wrong type
> DETAIL:  Table has type smallint, but query expects integer.

> Of course, in c1 the target column is #3 not #2.  The USING expression
> isn't being adjusted for the discrepancy between parent and child column
> numbers.

> This test case works before 9.5; somebody must have broke it while
> refactoring.

A little bit of "git bisect"-ing later, the blame is pinned on

commit 9550e8348b7965715789089555bb5a3fda8c269c
Author: Alvaro Herrera <alvherre@alvh.no-ip.org>
Date:   Fri Apr 3 17:33:05 2015 -0300
   Transform ALTER TABLE/SET TYPE/USING expr during parse analysis      This lets later stages have access to the
transformedexpression; in   particular it allows DDL-deparsing code during event triggers to pass   the transformed
expressionto ruleutils.c, so that the complete command   can be deparsed.      This shuffles the timing of the
transformcalls a bit: previously,   nothing was transformed during parse analysis, and only the   RELKIND_RELATION case
wasbeing handled during execution.  After this   patch, all expressions are transformed during parse analysis
(including  those for relkinds other than RELATION), and the error for other   relation kinds is thrown only during
execution. So we do more work than   before to reject some bogus cases.  That seems acceptable.
 


Of course, the reason why this work was postponed until execution was
exactly because we wanted to do it over again for each child table.

We could probably fix the specific issue being seen here by passing the
expression tree through a suitable attno remapping, but I am now filled
with dread about how much of the event trigger code may be naively
supposing that child tables have the same attnums as their parents.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] increasing the default WAL segment size
Next
From: Peter Eisentraut
Date:
Subject: Re: [HACKERS] Logical Replication WIP