Feedback-ID: ia2694551:Fastmail
Date: Fri, 4 Nov 2022 12:00:41 +0100
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Bruce Momjian <bruce@momjian.us>,
	"David G. Johnston" <david.g.johnston@gmail.com>,
	"lxndrkrlv@gmail.com" <lxndrkrlv@gmail.com>,
	"pgsql-bugs@lists.postgresql.org" <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #17233: Incorrect behavior of DELETE command with bad
 subquery in WHERE clause
Message-ID: <20221104110041.3a6tngpyqzod4p4p@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4158934.1661104235@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/20221104110041.3a6tngpyqzod4p4p%40alvherre.pgsql>
Precedence: bulk

I gave this a quick spin and couldn't find any faults.

The bit about getting an incorrect hint when p_rel_visible is false had
me busy for a little while (specifically I ran into it with the
"unnamed_subquery" stuff added by commit bcedd8f5fce0), but maybe that's
a fringe enough case, as the comment in rte_visible_if_lateral says.

I did wonder why errorMissingColumn doesn't consider rte_visible_if_* in
the case when there *is* an rsecond candidate.  I understand that the
reason is that if we come across any exact match we already return that
one without looking for a second one.  Maybe this deserves a comment (in
errorMissingColumn I mean) but I also wonder if we shouldn't scan the
whole RT in case there's another exact match that's also not visible.

-- 
Álvaro Herrera        Breisgau, Deutschland  —  https://www.EnterpriseDB.com/
"Learn about compilers. Then everything looks like either a compiler or
a database, and now you have two problems but one of them is fun."
            https://twitter.com/thingskatedid/status/1456027786158776329