Re: [HACKERS] ALTER TABLE .. ALTER COLUMN .. ERROR: attribute .. has wrong type

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