Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjIM6-0001Dp-Qu for pgsql-docs@arkaria.postgresql.org; Tue, 15 Jan 2019 06:37:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gjIM5-0007jC-EM for pgsql-docs@arkaria.postgresql.org; Tue, 15 Jan 2019 06:37:45 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjIM5-0007iO-6C for pgsql-docs@lists.postgresql.org; Tue, 15 Jan 2019 06:37:45 +0000 Received: from forward106j.mail.yandex.net ([2a02:6b8:0:801:2::109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gjIM2-00062o-84 for pgsql-docs@lists.postgresql.org; Tue, 15 Jan 2019 06:37:44 +0000 Received: from mxback9g.mail.yandex.net (mxback9g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:170]) by forward106j.mail.yandex.net (Yandex) with ESMTP id 5988F225B8; Tue, 15 Jan 2019 09:37:39 +0300 (MSK) Received: from smtp3p.mail.yandex.net (smtp3p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:8]) by mxback9g.mail.yandex.net (nwsmtp/Yandex) with ESMTP id sxEGPAhhh6-bdHOPWgu; Tue, 15 Jan 2019 09:37:39 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1547534259; bh=pIdN0UkuaEMM1Oh75JppTjHjbVC6Ltcxpcnm24/g+88=; h=Date:From:Message-ID:To:CC:Subject:In-Reply-To:References; b=KqY7rKEGzLVAUzVZujDSUmgGvGdS54aaOPofRFl5B32pdXiYYgbIb93IQehYCyoG2 LY5kwVwxB7X+D/450Eba6OlLQ1zJ/KRuCXzVcZ7k3+oLr9Xgzl0sfd61Jqkc7PwNc6 6a/Q2GQdEmiuhogJnLI5RldimVfUXJIMNP48j+H0= Authentication-Results: mxback9g.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by smtp3p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id UPZOWHYP5z-bcOmX8Kk; Tue, 15 Jan 2019 09:37:38 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client certificate not present) Date: Tue, 15 Jan 2019 08:37:37 +0200 From: Eugen Konkov Message-ID: <1382435334.20190115083737@yandex.ru> To: Tom Lane CC: pgsql-docs@lists.postgresql.org Subject: Re: DOC not so clear In-Reply-To: <25974.1547482531@sss.pgh.pa.us> References: <154747695538.22759.12913505368136831904@wrigleys.postgresql.org> <25974.1547482531@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Hello Tom, Monday, January 14, 2019, 6:15:31 PM, you wrote: > =?utf-8?q?PG_Doc_comments_form?= writes: >> https://www.postgresql.org/docs/current/queries-table-expressions.html#QUERIES-LATERAL >>> The resulting row(s) are joined as usual with the rows they were computed >>> from. >> Here is not so clear what 'joined as usual' mean. > Why not? Advanced users may understand that, but from my beginner point of view this is not. I do not understand that sentence until read whole text and about LEFT JOIN LATERAL. Even now 'usual' may mean: CROSS/RIGHT/FULL?? >> Probably DOC should explicitly say that if LATERAL function return empty set >> then current row is excluded from result set > That would be wrong for "LEFT JOIN LATERAL ...", so it does not seem > like an improvement. LATERAL != LEFT JOIN LATERAL it would be more clear if DOC will be more explicit. > regards, tom lane -- Best regards, Eugen Konkov