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 <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:
http://www.postgresql.org/mailpref/pgsql-hackers
