From: Tom Lane <tgl@sss.pgh.pa.us>
To: gurmokh.sangha@starlingbank.com
cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #17754: Subquery IN clause returns row matches where subquery
 is invalid
In-reply-to: <17754-0c04a53e0078e5d6@postgresql.org>
References: <17754-0c04a53e0078e5d6@postgresql.org>
Comments: In-reply-to PG Bug reporting form <noreply@postgresql.org>
	message dated "Thu, 19 Jan 2023 18:02:11 +0000"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <4191910.1674157368.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Thu, 19 Jan 2023 14:42:48 -0500
Message-ID: <4191911.1674157368@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/4191911.1674157368%40sss.pgh.pa.us>
Precedence: bulk

PG Bug reporting form <noreply@postgresql.org> writes:
> A subquery that has an incorrect column name, that happens to match a co=
lumn
> name in the outer query evaluates as true for all rows in the outer quer=
y.

Such a reference is called an "outer reference", and it's a required
feature in the SQL standard.  The reason you get "true" is that the
expression

> where a in ( select a from btable where c =3D 10) ;

is basically reducing to "a =3D a".

https://wiki.postgresql.org/wiki/FAQ#Why_doesn.27t_PostgreSQL_report_a_col=
umn_not_found_error_when_using_the_wrong_name_in_a_subquery.3F

			regards, tom lane