Tom Lane wrote: > 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,
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
