Heikki Linnakangas <heikki@enterprisedb.com> writes:
> Oh, the query actually gives an assertion failure on an
> assertion-enabled build, so this is clearly a bug:
> TRAP: FailedAssertion("!(attnum > 0 && attnum <=
> list_length(rte->joinaliasvars))", File: "parse_relation.c", Line: 1697)
Okay, I looked at this more closely and realized that our earlier
discussion was a bit beside the point. It's true that we can't
support a targetlist within any single plan tree that exceeds 1600
items, but that is not what the problem is here. The problem here
is that the described query generates a JOIN RTE having more than
32K join alias entries, and that means that it's impossible to build
a Var referencing the alias entries that're further down in the list,
because varattno is only int16. This is independent of how many
targetlist entries are actually requested.
I think the only sane approach to closing the bug in the stable branches
is to throw error if there's more than 32K columns in a join RTE.
The question is whether it's really worthwhile to do more than that
in HEAD. I think that people using reasonable table designs are never
going to run into this limitation anyway.
I don't much like the proposed patch --- widening AttrNumber seems
saner, or else splitting it into two types, one for varattno and
one for table column indexes and targetlist indexes. But even
phrasing it that way makes it sound pretty silly. Most Vars will
be referring to things that can't possibly exceed 1600.
I was thinking a day or two ago about fixing the planner's problems with
non-nullable subselect outputs underneath outer joins, and one of the
thoughts there was that we might be able to get rid of join alias vars
entirely if we had a brighter solution. Or at least not build the
entire dang list, but only the entries actually needed in the query.
What I propose we do is throw error for the moment, and make a TODO
note to revisit the question after redesigning outer-join planning.
Which is something I do intend to do for 8.4.
regards, tom lane
