Richard Guo <guofenglinux@gmail.com> writes:
> The underlying expression of a join alias Var can only be a Var
> (potentially coerced) from one of the join's input rels, or a COALESCE
> expression containing the two input Vars. Therefore, it should not be
> able to contain SRFs or volatile functions, and thus we do not need to
> expand it beforehand.
[ itch... ] That statement is false in general, because subquery
pullup within the subquery can replace a sub-subquery's output Vars
with expressions. It might be okay for this purpose, as I think we'd
not pull up if the sub-subquery's output expressions are volatile or
SRFs. These assumptions had better be well commented though.
The larger point here is that this behavior is all recursive,
and we can happily end with an expression that's been pulled up
several levels; we'd better make sure the right checks happen.
So I'm a little bit distressed that planner.c's invocations of
flatten_group_exprs are not at all analogous to its usage of
flatten_join_alias_vars. The latter pattern has a couple of
decades of usage to lend credence to the assumption that it's
correct. flatten_group_exprs, um, not so much. It may be
fine, given the fact that grouping Vars can appear within
much less of the query than join aliases. But in view of the
present bug, I'm feeling nervous.
regards, tom lane
