Re: BUG #15471: psql 11 array concatenation in CASE takes on values from the CASE expression when using enum_range

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)

In response to

Responses

Browse pgsql-bugs by date

  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