Re: BUG #15471: psql 11 array concatenation in CASE takes on values from the CASE expression when using enum_range
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andrew Gierth <andrew@tao11.riddles.org.uk>
Cc: pg@mattyw.net, pgsql-bugs@lists.postgresql.org,
Andres Freund <andres@anarazel.de>
Date: 2018-10-30T13:30:54Z
Lists: pgsql-bugs
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
Commits
-
Fix interaction of CASE and ArrayCoerceExpr.
- 2bd6dcdeff09 11.1 landed
- 14a158f9bff1 12.0 landed
-
Teach eval_const_expressions() to handle some more cases.
- 3decd150a2d5 11.0 cited
-
Support arrays over domains.
- c12d570fa147 11.0 cited