Re: BUG #15471: psql 11 array concatenation in CASE takes on values from the CASE expression when using enum_range
От | Tom Lane |
---|---|
Тема | Re: BUG #15471: psql 11 array concatenation in CASE takes on values from the CASE expression when using enum_range |
Дата | |
Msg-id | 15342.1540906254@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: BUG #15471: psql 11 array concatenation in CASE takes on values from the CASE expression when using enum_range (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: BUG #15471: psql 11 array concatenation in CASE takes on valuesfrom the CASE expression when using enum_range
|
Список | 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
В списке pgsql-bugs по дате отправления: