Re: BUG #18327: Column naming inconsistency for boolean literals in ELSE clauses of CASE expressions.

On Sun, Feb 4, 2024, 11:19 PG Bug reporting form <noreply(at)postgresql(dot)org>
wrote:

> The following bug has been logged on the website:
>
> Bug reference: 18327
> Logged by: Michael Bondarenko
> Email address: work(dot)michael(dot)2956(at)gmail(dot)com
> PostgreSQL version: 14.10
> Operating system: MacOS Sonoma 14.1.1 (23B81)
> Description:
>
> I'm running my queries on the TPC-H schema, which can be found at:
> https://github.com/dimitri/tpch-citus/blob/master/schema/tpch-schema.sql
>
> I found the following inconsistency:

This one doesn't have a name to use. Using case is better than picking one
of the branches to make up a name from.

> ```
> tpch=# select case when true then true else true end;
> case
> ------
> t
> (1 row)
>

All of these do. And in any case we never publish how we choose our
aliases in this circumstance so it cannot be a bug.

The subquery forces a name to be chosen for the output relation. Then
since only one branch has a name to provide it is used.

> tpch=# select case when true then true else (select true) end;
> bool
> ------
> t
> (1 row)
> ```
>
> As you can see, the auto-generated aliases do not correspond. The expected
> behaviour was for the first query to also name the column 'bool'.
>
> I base my expectations on:
>
> 1) This query naming the result 'bool':
> ```
> tpch=# select true;
> bool
> ------
> t
> (1 row)
> ```
>
> 2) These queries propagating the column name from the else clause of the
> case expression:

2.1) Propagation of the aggregate function name
> ```
> tpch=# select case when true then true else bool_or(true) end;
> bool_or
> ---------
> t
> (1 row)
> ```
>

This is indeed all consistent in that literals don't have names while other
expression tend to.

David J.