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