I wrote:
> Hah:

> regression=# create table p(f1 int);
> regression=# create table c1(extra smallint) inherits(p);
> regression=# alter table p add column f2 int;
> 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 <alvhe...@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 transformed expression; in
    particular it allows DDL-deparsing code during event triggers to pass
    the transformed expression to ruleutils.c, so that the complete command
    can be deparsed.
    This shuffles the timing of the transform calls a bit: previously,
    nothing was transformed during parse analysis, and only the
    RELKIND_RELATION case was being 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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to