I looked into the problem reported here:
http://www.postgresql.org/message-id/E1VCmgF-0001uF-9I@wrigleys.postgresql.org
What's happening is that the Var that represents "my_col" in the outer
query has typmod -1, but after we inline the SQL function we can see that
what it returns is varchar(5), so build_physical_tlist generates a Var
with a positive typmod to represent the sub-select's output, and then
locate_grouping_columns fails to match that to the original Var.
It's a bit surprising that we've not seen any reports like this before.
The failure is hidden in many similar cases because if the inlined
subquery is pulled up, the Vars referencing it will be replaced with
subquery outputs. But that still leaves a pretty fair number of cases
where you could see the failure.
I don't see any very nice way to eliminate the potential mismatch of
typmods, so what I'm thinking is that locate_grouping_columns shouldn't
use tlist_member() (which compares using equal()) to search the physical
tlist for a match. Rather, it can depend on the fact that the grouping
column must be a Var (cf. make_subplanTargetList) and just look for a
Var with the same varno/varattno.
Anyone have a better idea?
regards, tom lane
