| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Björn Kautler <Bjoern(at)kautler(dot)net>, Tender Wang <tndrwang(at)gmail(dot)com>, "pgsql-bugs(at)lists(dot)postgresql(dot)org" <pgsql-bugs(at)lists(dot)postgresql(dot)org>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
| Subject: | Re: GROUP BY in CTE causes ELSE in outer query to be prematurely evaluated |
| Date: | 2026-03-04 20:37:22 |
| Message-ID: | 1656487.1772656642@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
"David G. Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> writes:
> On Wednesday, March 4, 2026, Björn Kautler <Bjoern(at)kautler(dot)net> wrote:
>> What I tried to do was to provoke the division-by-zero error if I happened
>> to forget some WHEN branch as this is a bug.
>> Is there some safe way to do something like this you are aware of
> Write a volatile “fail()” plpgsql function, and call it in the else block.
> Raise exception there.
Right. An intentional failure is a side-effect, and immutable
subexpressions are not supposed to have side-effects. As long
as you mark the fail() function volatile, the planner will avoid
pre-evaluating it.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Rafia Sabih | 2026-03-05 01:01:34 | Re: Two issues with REFRESH MATERIALIZED VIEW CONCURRENTLY |
| Previous Message | David G. Johnston | 2026-03-04 19:32:04 | Re: GROUP BY in CTE causes ELSE in outer query to be prematurely evaluated |