Tom Lane wrote:
> 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 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,
Hmm, ouch. I can look into fixing this starting tomorrow afternoon.
> 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.
I guess it's on me to figure that out.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services