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

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Chris BSomething <xpusostomos(at)gmail(dot)com>
Cc: PostgreSQL Bug List <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #18594: CASE WHEN ELSE failing to return the expected output when the same colum is used in WHEN and ELSE
Date: 2025-02-17 22:31:22
Message-ID: CAKFQuwZ2Rk4T+NWM6uLbooEmg9ADUPb9MqBvqFceK_c2+RyKBQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Chris BSomething 2025-02-17 22:49:40 Re: BUG #18594: CASE WHEN ELSE failing to return the expected output when the same colum is used in WHEN and ELSE
Previous Message Tom Lane 2025-02-17 20:57:30 Re: BUG #18815: Logical replication worker Segmentation fault