| From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> | 
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> | 
| Cc: | pg(at)mattyw(dot)net, pgsql-bugs(at)lists(dot)postgresql(dot)org, Andres Freund <andres(at)anarazel(dot)de> | 
| Subject: | Re: BUG #15471: psql 11 array concatenation in CASE takes on values from the CASE expression when using enum_range | 
| Date: | 2018-10-30 12:49:25 | 
| Message-ID: | 87efc77gh2.fsf@news-spur.riddles.org.uk | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-bugs | 
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
 >> Below is an example .sql file that replicates the problem. Put
 >> simply, when we array concat with enum_range in the result of a CASE
 >> statement the concatenation takes the expression from the CASE
 >> statement, not the enum range.
 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).
What's going on in eval_const_expressions_mutator is that
context->case_val is set when recursing into the elemexpr in the
ArrayCoerceExpr case, so when that sees a CaseTestExpr inside that, it
replaces it (incorrectly).
-- 
Andrew (irc:RhodiumToad)
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andrew Gierth | 2018-10-30 13:09:40 | Re: BUG #15467: The database subdirectory "pg_tblspc/1932420460/PG_10_201707211/16400" is missing. | 
| Previous Message | Tom Lane | 2018-10-30 11:59:35 | Re: BUG #15471: psql 11 array concatenation in CASE takes on values from the CASE expression when using enum_range |