Re: BUG #18327: Column naming inconsistency for boolean literals in ELSE clauses of CASE expressions. - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #18327: Column naming inconsistency for boolean literals in ELSE clauses of CASE expressions.
Date
Msg-id 3934130.1707076663@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #18327: Column naming inconsistency for boolean literals in ELSE clauses of CASE expressions.  ("David G. Johnston" <david.g.johnston@gmail.com>)
List pgsql-bugs
"David G. Johnston" <david.g.johnston@gmail.com> writes:
> This is indeed all consistent in that literals don't have names while other
> expression tend to.

Actually, pre-v15 the literal constants "true" and "false" do have
names for this purpose.  For historical reasons they were parsed
into the equivalent of 't'::bool and 'f'::bool, and then the name
selection rule for a typecast took effect.

Starting in v15 they're treated like other sorts of literals,
meaning they have no assigned name:

regression=# select true;
 ?column? 
----------
 t
(1 row)

Many of these other examples change as a consequence.

            regards, tom lane



pgsql-bugs by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: BUG #18327: Column naming inconsistency for boolean literals in ELSE clauses of CASE expressions.
Next
From: PG Bug reporting form
Date:
Subject: BUG #18330: The query planner chooses the wrong plan when using the parallel aggregation function