I said:
> While I now need to burrow into the IN-as-join code and find out where
> it's dropping the ball, I don't think this need stop you from making
> progress on the information schema. The reason the problem is appearing
> seems to be the implied cast that's getting introduced in the IN
> comparison,
This theory turns out to be mistaken, or at least only marginally
relevant; it's possible to make the problem happen with no casts
at all. I think the reason that adding or removing a cast made the
problem appear/disappear for me was just that it changed which plan
got selected (since the estimation routines are not very bright about
coping with joins on expressions). The failure occurs when the planner
chooses to implement an IN by unique-ifying the result of the sub-select
and then using that as the outer side of a join. If that join is not
the topmost join of the whole plan, we fail --- because the unique-ified
plan node only emits the variables that are supposed to be used in the
IN comparison, but the upper join generates a targetlist that includes
every variable used anywhere in the query.
If you hit the problem again, you might find that turning off
enable_hashagg lets you make progress. A real solution seems to require
some honest accounting for which variables need to appear in join
targetlists and which don't; I'm off to look at that now ...
regards, tom lane
