Re: Small problem with PlaceHolderVar mechanism

Greg Stark <stark(at)enterprisedb(dot)com> writes:
> On Tue, Apr 28, 2009 at 4:41 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Another place where planner regression tests might've helped :-(

> I would suggest we start gathering up such tests in an sql file now
> and worry about how to compare the output later.

If anyone feels like doing the legwork, there are interesting examples
in the CVS commit logs. I happened to notice the current problem while
I was re-reading the logs whilst checking the release notes. For no
particularly good reason I retried the examples mentioned in this item,
and behold it wasn't what I expected ...

2008-08-17 15:40 tgl

* src/backend/optimizer/path/joinrels.c: Add some defenses against
constant-FALSE outer join conditions. Since eval_const_expressions
will generally throw away anything that's ANDed with constant
FALSE, what we're left with given an example like

select * from tenk1 a where (unique1,0) in (select unique2,1 from
tenk1 b);

is a cartesian product computation, which is really not acceptable.
This is a regression in CVS HEAD compared to previous releases,
which were able to notice the impossible join condition in this
case --- though not in some related cases that are also improved by
this patch, such as

select * from tenk1 a left join tenk1 b on (a.unique1=b.unique2 and
0=1);

Fix by skipping evaluation of the appropriate side of the outer
join in cases where it's demonstrably unnecessary.

regards, tom lane