Re: Soon-to-be-broken regression test case

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>, Jeevan Chalke <jeevan.chalke@enterprisedb.com>, pgsql-hackers@lists.postgresql.org, David Rowley <david.rowley@2ndquadrant.com>
Date: 2018-10-11T17:19:11Z
Lists: pgsql-hackers
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> On 2018-Oct-11, Tom Lane wrote:
>> Hm, I'm not seeing any regression test result changes there.  However,
>> if you're just executing queries and not EXPLAIN'ing them, it's possible
>> something unwanted is happening under the hood.

> Hmm, no, the explains are there.  Here's one example -- maybe your new
> planner smarts do not change these plans for some reason

Oh, I see --- these are just "scalar-result sub-SELECTs", not
sub-select-in-FROM, so they never get into the join tree to begin with.
WHERE EXISTS is an exception because we attempt to translate it to a
JOIN_SEMI join, exposing an opportunity for subquery pullup.

			regards, tom lane


Commits

  1. Make some subquery-using test cases a bit more robust.

  2. Prevent generation of bogus subquery scan paths.