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

"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Wed, Jan 22, 2025 at 3:00 AM Chris BSomething <xpusostomos(at)gmail(dot)com>
> wrote:
>> ... should there not be a new rule,
>> something like considering if the unknown types can be converted, then
>> notice that a long string can't be converted to a char, because it won't
>> fit? And then fail with an interesting error?

> Do you have an example demonstrating this new rule? I'm doubting this
> resolution logic goes into that much depth regarding the semantics of each
> type. It is implied that even if an implicit cast exists from type A to
> type B that actual values of type A may fail during the casting process to
> make them type B. That would be the interesting error you'd end up seeing
> - but from the type casting/input system, not the type resolution one.

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.

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",
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.

regards, tom lane