pull_up_simple_subquery

While working on KaiGai's "leaky views" patch, I found myself
scrutinizing the behavior of the function named in the subject line;
and specifically the retest of is_simple_subquery(). I've been unable
to make that fail. For example, the following patch fails to break
the regression tests:

--- a/src/backend/optimizer/prep/prepjointree.c
+++ b/src/backend/optimizer/prep/prepjointree.c
@@ -718,6 +718,7 @@ pull_up_simple_subquery(PlannerInfo *root, Node *jtnode, Ran
}
else
{
+ elog(ERROR, "croak and die");
/*
* Give up, return unmodified RangeTblRef.
*

This logic was originally introduced by the following commit:

commit e439fef6fc3e81aeb865f2c5a77c6faa2ee2a931
Author: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Date: Sat Jan 10 00:30:21 2004 +0000

Fix subquery pullup logic to not be fooled when a view that appears
'simple' references another view that is not simple. Must recheck
conditions after performing recursive pullup. Per example from
Laurent Perez, 9-Jan-04.

However, despite my best efforts, I can't figure out what scenario
it's protecting us against, at least not on current sources. The
original bug report is here:

http://archives.postgresql.org/pgsql-general/2004-01/msg00375.php

Tom's reply indicates that the v4 example shouldn't get flattened, but
it looks to me like current sources do flatten it and I really don't
see why they shouldn't. Poking around with git bisect and the patch
shown above, I see that the test case stopped tickling this code with
commit e6ae3b5dbf2c07bceb737c5a0ff199b1156051d1, which introduced
PlaceHolderVars, apparently for the precise purpose of allowing joins
of this type to be flattened. But this code survived that commit,
leaving the question of whether there are still cases where it's
needed (in which case we should probably add a comment or regression
test case, since it's not at all obvious) or whether we can rip it out
and save a few cycles.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company