From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rowley <dgrowleyml(at)gmail(dot)com> |
Cc: | Vik Fearing <vik(at)postgresfriends(dot)org>, Marek Malevič <marek(at)malevicovi(dot)net>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Broken type checking for empty subqueries |
Date: | 2023-09-28 14:57:39 |
Message-ID: | 960060.1695913059@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
David Rowley <dgrowleyml(at)gmail(dot)com> writes:
> I've not looked at the code to see if this would be practical or not,
> but I wonder if we could reduce these bug reports by using the new
> soft error reporting that's now done in the input functions to have
> constant folding just silently not do any folding for the expression
> if a cast fails.
Sadly, I doubt that would cover enough of the problem space to make
much difference to people who try to do this sort of thing.
> ... I imagine most people who
> have had them fail during constant folding have just redesigned or
> found some hack to prevent the folding from taking place anyway.
Yeah. The given query looks like it was already hacked to avoid
constant-folding, though I wonder if whoever wrote it really understood
that. Otherwise it'd be a lot more natural to use something like CASE.
Anyway, adding OFFSET 0 to suppress sub-select folding is probably
the best answer here.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Akash Kava | 2023-09-28 15:04:54 | Re: BUG #18138: Using limit on VALUES causes type conversion to fail. |
Previous Message | David Rowley | 2023-09-28 14:47:01 | Re: Broken type checking for empty subqueries |