Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ewUnJ-00038v-Ry for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Mar 2018 15:27:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ewUnI-0003NR-QL for pgsql-hackers@arkaria.postgresql.org; Thu, 15 Mar 2018 15:27:52 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ewUnI-0003NI-JS for pgsql-hackers@lists.postgresql.org; Thu, 15 Mar 2018 15:27:52 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1ewUnB-0006De-Ru for pgsql-hackers@lists.postgresql.org; Thu, 15 Mar 2018 15:27:52 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id w2FFRiUS015945 for ; Thu, 15 Mar 2018 11:27:44 -0400 From: Tom Lane To: pgsql-hackers@lists.postgresql.org Subject: "SELECT ... FROM DUAL" is not quite as silly as it appears MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15943.1521127664.1@sss.pgh.pa.us> Date: Thu, 15 Mar 2018 11:27:44 -0400 Message-ID: <15944.1521127664@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk We've long made fun of Oracle(TM) for the fact that if you just want to evaluate some expressions, you have to write "select ... from dual" rather than just "select ...". But I've realized recently that there's a bit of method in that madness after all. Specifically, having to cope with FromExprs that contain no base relation is fairly problematic in the planner. prepjointree.c is basically unable to cope with flattening a subquery that looks that way, although we've inserted a lot of overly-baroque logic to handle some subsets of the case (cf is_simple_subquery(), around line 1500). If memory serves, there are other places that are complicated by the case. Suppose that, either in the rewriter or early in the planner, we were to replace such cases with nonempty FromExprs, by adding a dummy RTE representing a table with no columns and one row. This would in turn give rise to an ordinary Path that converts to a Result plan, so that the case is handled without any special contortions later. Then there is no case where we don't have a nonempty relids set identifying a subquery, so that all that special-case hackery in prepjointree.c goes away, and we can simplify whatever else is having a hard time with it. I'm not planning to do anything about this soon (ie, not before v12), but I thought I'd get the ideas down on electrons before they vanish. regards, tom lane