I looked into the problem reported here: http://www.postgresql.org/message-id/e1vcmgf-0001uf...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers