From: Tom Lane <tgl@sss.pgh.pa.us>
To: "David G. Johnston" <david.g.johnston@gmail.com>
cc: zabetak@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17623: WHERE should be evaluated after FROM clause when
 operators may throw
In-reply-to: 
 <CAKFQuwbRN3ji2jQzPqGeSpLyYCGg3WZnheQUjvXSN52VW-YKGg@mail.gmail.com>
References: <17623-2bef2f4ff7fe8051@postgresql.org>
 <CAKFQuwbRN3ji2jQzPqGeSpLyYCGg3WZnheQUjvXSN52VW-YKGg@mail.gmail.com>
Comments: In-reply-to "David G. Johnston" <david.g.johnston@gmail.com>
	message dated "Wed, 28 Sep 2022 06:56:26 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3945738.1664375858.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Wed, 28 Sep 2022 10:37:38 -0400
Message-ID: <3945739.1664375858@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/3945739.1664375858%40sss.pgh.pa.us>
Precedence: bulk

"David G. Johnston" <david.g.johnston@gmail.com> writes:
>> The SQL standard (Section 7.4 general rule 1) mandates that WHERE shoul=
d be
>> applied to the result of FROM so in the case above pushing filters belo=
w
>> the join seems to violate the standard.

> The failure to document such a deviation from the standard can be
> considered a bug but not the deviation itself.  That is intentional.  In
> terms of trade-offs the current behavior seems reasonable.

Enforcing such a restriction would be absolutely disastrous for the
performance of a large number of real-world queries.  I doubt that
any other RDBMS takes that spec wording literally either.

I'd suggest something like

	CASE WHEN e.empno =3D 0 THEN NULL ELSE 10 / e.empno END

if you need to program around the lack of guarantees about the
order of evaluation.  A WITH clause can also be used as an
optimization fence when you need one.

BTW, this *is* documented, see for example

https://www.postgresql.org/docs/current/sql-expressions.html#SYNTAX-EXPRES=
S-EVAL

			regards, tom lane