Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bfpKt-0008RH-6E for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Sep 2016 14:20:51 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1bfpKs-0006P1-L0 for pgsql-hackers@arkaria.postgresql.org; Fri, 02 Sep 2016 14:20:50 +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.84_2) (envelope-from ) id 1bfpKq-0006L3-P1 for pgsql-hackers@postgresql.org; Fri, 02 Sep 2016 14:20:48 +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.84_2) (envelope-from ) id 1bfpKn-0001xf-V9 for pgsql-hackers@postgresql.org; Fri, 02 Sep 2016 14:20:48 +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 u82EKgaw009966; Fri, 2 Sep 2016 10:20:42 -0400 From: Tom Lane To: Andres Freund cc: Kevin Grittner , Robert Haas , "pgsql-hackers@postgresql.org" Subject: Re: Implement targetlist SRFs using ROWS FROM() (was Changed SRF in targetlist handling) In-reply-to: <20160902141110.6xciuntt5h4i6eni@alap3.anarazel.de> References: <20160523005327.v2tr7obytitxcnna@alap3.anarazel.de> <20160822214023.aaxz5l4igypowyri@alap3.anarazel.de> <20160902141110.6xciuntt5h4i6eni@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Fri, 02 Sep 2016 07:11:10 -0700" Date: Fri, 02 Sep 2016 10:20:42 -0400 Message-ID: <9965.1472826042@sss.pgh.pa.us> X-Pg-Spam-Score: -3.4 (---) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-hackers Precedence: bulk Sender: pgsql-hackers-owner@postgresql.org Andres Freund writes: > On 2016-09-02 09:05:35 -0500, Kevin Grittner wrote: >>> In general, we've been skeptical about giving any guarantees about >>> result ordering. > Well, it's historically how we behaved for SRFs. I'm pretty sure that > people will be confused if > SELECT generate_series(1, 10) FROM sometbl; > suddenly returns rows in an order that reverse from what > generate_series() returns. True, but how much "enforcement" do we need really? This will be a cross product join, which means that it can only be done as a nestloop not as a merge or hash (there being no join key to merge or hash on). ISTM all we need is that the SRF be on the inside of the join, which is automatic if it's LATERAL. >> I think it is a very bad idea to move away from the statement that >> a query generates a set of rows, and that no order is guaranteed >> unless the top level has an ORDER BY clause. How hard is it to add >> ORDER BY 1, 2 to the above query? Let the optimizer notice when a >> node returns data in the needed order and skip the sort if possible. > There's no such infrastructure for SRFS/ROWS FROM. And in particular nothing to ORDER BY in this example. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers