Richard Guo <guofenglinux@gmail.com> writes:
> Yeah, it's not the fault of the plan cache. I noticed this because in
> check_ungrouped_columns, both Const and Param are treated as always
> acceptable. However, in setrefs.c these two expression types are
> handled differently: Const is never matched to the lower tlist, while
> Param is always attempted to be matched to the lower tlist. This
> discrepancy causes the query in the example to behave differently
> depending on the plan cache mode.
> I'm unsure which behavior is the expected one.
I'm unsure why you think they need to have the same behavior.
This code is correct given the assumption that a Const is as constant
as it seems on the surface. The trouble we're hitting is that in
the presence of grouping-set keys that reduce to Consts, a reference
to such a key is *not* constant. The right answer to that IMO is to
not represent those references as plain Const nodes.
> Another related question I have is about the behavior of the following
> query:
> select 3 as c1, 3 as c2 from generate_series(1,2) t group by
> rollup(c1) having 3 = 3;
> Should the target entry 'c2', as well as the Const expressions in
> havingQual, be replaced with references to the grouping key?
This seems rather analogous to our occasional debates about whether
textually distinct uses of "random()" should refer to the same
value or different evaluations. I can't get very excited about it,
because it seems to me this is an academic example not corresponding
to any real use-case. The current code seems to effectively assume
that the constant-instances are distinct even though textually
identical, and that's fine with me.
regards, tom lane
