Check we don't misoptimize a NOT IN where the subquery returns no rows.

Future-proofing against a common mistake in attempts to optimize NOT IN.
We don't have such an optimization right now, but attempts to do so
are in the works, and some of 'em are buggy.  Add a regression test case
covering the point.

David Rowley

Discussion: https://postgr.es/m/CAKJS1f90E9agVZryVyUpbHQbjTt5ExqS2Fsodmt5_A7E_cEyVA@mail.gmail.com
This commit is contained in:
Tom Lane 2019-03-01 17:57:20 -05:00
parent 65ce07e020
commit 3396138a6d
2 changed files with 22 additions and 0 deletions

View File

@ -830,6 +830,19 @@ explain (verbose, costs off)
One-Time Filter: ("*VALUES*".column1 = "*VALUES*".column1)
(8 rows)
--
-- Check we don't misoptimize a NOT IN where the subquery returns no rows.
--
create temp table notinouter (a int);
create temp table notininner (b int not null);
insert into notinouter values (null), (1);
select * from notinouter where a not in (select b from notininner);
a
---
1
(2 rows)
--
-- Check we behave sanely in corner case of empty SELECT list (bug #8648)
--

View File

@ -466,6 +466,15 @@ explain (verbose, costs off)
select x, x from
(select (select random() where y=y) as x from (values(1),(2)) v(y)) ss;
--
-- Check we don't misoptimize a NOT IN where the subquery returns no rows.
--
create temp table notinouter (a int);
create temp table notininner (b int not null);
insert into notinouter values (null), (1);
select * from notinouter where a not in (select b from notininner);
--
-- Check we behave sanely in corner case of empty SELECT list (bug #8648)
--