Re: BUG #18594: CASE WHEN ELSE failing to return the expected output when the same colum is used in WHEN and ELSE

Chris BSomething <xpusostomos@gmail.com>

From: Chris BSomething <xpusostomos@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: "David G. Johnston" <david.g.johnston@gmail.com>, PostgreSQL Bug List <pgsql-bugs@lists.postgresql.org>
Date: 2025-02-19T12:50:22Z
Lists: pgsql-bugs
On Tue, 18 Feb 2025 at 10:12, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Yeah.  We document somewhere that the contents of a literal string are
> *not* considered while deciding what type it should be taken as; thus,
> the possibility of a casting failure is not part of the rules.
>

The length of a literal is not strictly speaking its "contents". One could
for example, have its type as varchar(x) where x is its length. And then
not have implicit typecasts from varchar(x) to varchar( < x).


> I think such a rule would be pretty dangerous, even if we could
> implement it easily.  As an example, if you entered something you
> meant as a timestamp, but you fat-fingered the punctuation or
> something, it'd likely fall back to being considered just "text",
>

I don't get that, I thought timestamps have to be preceded by "TIMESTAMP".

 potentially silently changing the semantics of the expression.  We had

> a lot of trouble with that sort of behavior back when the system had a
> lot of implicit casts to text.  We got rid of (most of) those in 8.3
> or thereabouts, and it made the semantics generally a lot safer.


So... you solved that, it sounds like.

And yet this super dangerous behavior which could sit dormant and
undiscovered in a view in a large computer system, doesn't bother anyone?
OK, whatever.

Chris