I wrote:
> Therefore, my proposal here is to leave the parser's usage of
> CaseTestExpr alone, and replace CaseTestExprs with Params during
> eval_const_expressions, just before any relevant function inlining
> could happen.
I thought of a nasty defect in this idea: CASE expressions that would
have been seen as equal() may not be equal after the transformation.
(The upper nodes are fine because we can make their *param fields be
equal_ignore, but the lower PARAM_EXPRs won't match.) There's at
least one important behavior this probably breaks, which is matching
of index expressions containing a CASE or ArrayCoerce to query quals.
That might be a rare use-case, but it'd annoy anyone doing it, and
it'd be pretty hard to explain why it's not a bug.
I spent some time wondering if we could somehow number the Params
"bottom up" to fix this, so that (for example) a CASE would always
use paramid 1 unless it contains one other CASE, which would cause it
to use paramid 2, etc. I think eval_const_expressions could be made
to do that, but it's not clear how to preserve the property during
function inlining. But the main thing I don't like is that this would
make it much less obvious that Params with overlapping lifespans have
distinct IDs, which takes away a large part of the attraction of the
whole design.
Pending some better idea, I'm withdrawing this patch.
regards, tom lane
