Message-ID: <5ecbdb70a74b1101aba33cd6c03638c0244759c8.camel@j-davis.com>
Subject: Re: BUG #18965: Issue with Short-Circuit Evaluation in Boolean
 Expressions
From: Jeff Davis <pgsql@j-davis.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, brandystodd@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Date: Tue, 08 Jul 2025 10:48:43 -0700
In-Reply-To: <2145178.1750444630@sss.pgh.pa.us>
References: <18965-89456ea7e640a053@postgresql.org>
	 <2145178.1750444630@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.52.3-0ubuntu1 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/5ecbdb70a74b1101aba33cd6c03638c0244759c8.camel%40j-davis.com>
Precedence: bulk

On Fri, 2025-06-20 at 14:37 -0400, Tom Lane wrote:
> I think the fundamental problem you're having is that you marked
> this function IMMUTABLE, which gives the planner license to
> pre-evaluate it.=C2=A0 It had better be VOLATILE to discourage advance
> evaluation.
>=20
> https://www.postgresql.org/docs/current/xfunc-volatility.html

What you say is true in the narrow sense that VOLATILE prevents
planner-time evaluation. But it doesn't generalize into a mathematical
rule about how to mark a function: one might conclude (falsely)
that=C2=A0IMMUTABLE functions must not be able to throw exceptions, but
clearly they can. For instance, int4div():

EXPLAIN SELECT * FROM a WHERE (1/1 =3D 0);
                QUERY PLAN               =20
------------------------------------------
 Result  (cost=3D0.00..0.00 rows=3D0 width=3D0)
   One-Time Filter: false
(2 rows)

EXPLAIN SELECT * FROM a WHERE (1/0 =3D 0);
ERROR:  division by zero

If you try to fix that by marking int4div as VOLATILE, you'd have to do
the same for int4pl (which can overflow), and any function that can run
out of memory.

The way I see it, the problem is not the function marking, nor is it
the evaluation order. It's that there's an expression in the query
that's impossible to evaluate.

Todd, you mentioned that you started from a more complex scenario, can
you give some more details about how such an expression ended up in the
original query, and what you'd like to happen?

Regards,
	Jeff Davis