Date: Tue, 30 Oct 2018 10:42:00 -0700
From: Andres Freund <andres@anarazel.de>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pg@mattyw.net, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15471: psql 11 array concatenation in CASE takes on values
 from the CASE expression when using enum_range
Message-ID: <20181030174200.uht4cysuzcovgerx@alap3.anarazel.de>
References: <15471-1117f49271989bad@postgresql.org>
 <8112.1540900775@sss.pgh.pa.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <8112.1540900775@sss.pgh.pa.us>
Precedence: bulk

Hi,

On 2018-10-30 07:59:35 -0400, Tom Lane wrote:
> =?utf-8?q?PG_Bug_reporting_form?= <noreply@postgresql.org> 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.
> 
> Wow, that's ... bizarre.  I'm thinking that we probably did something
> silly in the big expression-execution rewrite, but it's not clear exactly
> where.

It can't be "the big one", because then it'd be in 10 too, right?

> So somehow the planner is messing up and inserting an outer CaseTestExpr
> value as the source of the elemexpr's coercion expression.  IIRC,
> ruleutils doesn't print the elemexpr at all, which is how come we're not
> seeing the mistake in the EXPLAIN output.
> 
> However, ArrayCoerceExpr has abused CaseTestExpr that way for awhile, so
> it's still not very clear why it broke in v11 and not before ...

Without further analysis, the only commit that looks midly relevant is

commit c12d570fa147d0ec273df53de3a2802925d551ba
Author: Tom Lane <tgl@sss.pgh.pa.us>
Date:   2017-09-30 13:40:56 -0400

    Support arrays over domains.

Greetings,

Andres Freund