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_ce...@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/3396138a6de329fa7b5e0dda79219b4ae82622dc Modified Files -------------- src/test/regress/expected/subselect.out | 13 +++++++++++++ src/test/regress/sql/subselect.sql | 9 +++++++++ 2 files changed, 22 insertions(+)
