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