Re: BUG #17637: case-when branches taken even if they dont match, raising errors

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Facundo Etchezar <hctf90(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Richard Guo <guofenglinux(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17637: case-when branches taken even if they dont match, raising errors
Date: 2022-10-14 13:28:11
Message-ID: CAKFQuwaCf4Weu4QqL5PHHX+YZBfB_mUD1vpRGh6gT-yd-RJvGg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

On Fri, Oct 14, 2022 at 12:23 AM Facundo Etchezar <hctf90(at)gmail(dot)com> wrote:

> I see. So is this behavior expected? The two snippets should work the same
> when you look at them but one errors out and the other doesn't. I'm
> thinking either both should work or both should error out.
>

While reasonable, this particular dynamic falls into a grey area. SQL is a
strongly typed language and having a column of data that is conditionally
in different data formats is not really compatible with that design. The
CASE expression does allow for handling of this typically but that only
works during execution - and in this case the problematic optimization is
happening during parsing. More people write structurally correct
inefficient queries than non-structurally correct ones and so the parsing
time optimization stays as-is. As noted, you have a way to prohibit the
optimization from revealing the design problem with your query.

David J.

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Michael Paquier 2022-10-15 02:47:49 Re: BUG #17640: fork off the requested timeline before the switchpoint.
Previous Message PG Bug reporting form 2022-10-14 05:21:48 BUG #17640: fork off the requested timeline before the switchpoint.