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: | Raw Message | Whole Thread | 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 |