Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:
> Tom> Wow, that's ... bizarre. I'm thinking that we probably did
> Tom> something silly in the big expression-execution rewrite, but it's
> Tom> not clear exactly where. Anyway, will look into it if Andres
> Tom> doesn't beat me to it.
> I took a look, and what I'm seeing suggests that commit 3decd150a2d
> might possibly be relevant here (at least to explain why it breaks in 11
> but not 10).
Good guess but I don't think that changed anything. It looks to me
like the culprit is commit c12d570fa, so it's my bug not Andres' :-(.
Before that, we weren't abusing CaseTestExpr as part of ArrayCoerceExpr.
Probably, the fix is to have eval_const_expressions be sure to
save/clear/restore context->case_val when dealing with ArrayCoerceExpr's
elemexpr. That possibly does mean that we have to undo the generic
processing of ArrayCoerceExpr, but it was already broken before that
transformation.
This is all some more fuel for the idea that we need a less messy
substitute for CaseTestExpr. As it happens, I was just fooling with
that yesterday, and hope to have something to post soon. But it'll
be too invasive to back-patch. I'll try to fix this particular
problem more locally.
regards, tom lane