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

On Tue, Feb 18, 2025, 6:31 AM David G. Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>
wrote:

> On Wed, Jan 22, 2025 at 3:00 AM Chris BSomething <xpusostomos(at)gmail(dot)com>
> wrote:
>
>> In the 6 rules for type resolution, rule 5 says "select the first
>> non-unknown input type as candidate, and consider if other non-unknown
>> types can be implicitly converted." ... 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.
>
> David J.
>

That sounds like a lot of words to justify an error that could be caught at
parse time, that is actually never caught at all. It seems to me that
whatever type is inferred from a long constant string, it won't fit into a
char... At least not without casting it. And therefore an error should come
out.

>