Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mZJwv-0000uL-40 for pgsql-docs@arkaria.postgresql.org; Sat, 09 Oct 2021 21:32:09 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mZJwM-0007TZ-LC for pgsql-docs@arkaria.postgresql.org; Sat, 09 Oct 2021 21:31:34 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mZJwL-0007TP-Rk for pgsql-docs@lists.postgresql.org; Sat, 09 Oct 2021 21:31:34 +0000 Received: from resdmta-ch2-01v.sys.comcast.net ([2001:558:fe21:29:69:252:207:81]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mZJwI-0001Eo-HO for pgsql-docs@lists.postgresql.org; Sat, 09 Oct 2021 21:31:31 +0000 Received: from resqmta-ch2-10v.sys.comcast.net ([69.252.207.42]) by resdmta-ch2-01v.sys.comcast.net with ESMTP id ZIZVm7OhfTKfNZJwFmQOhz; Sat, 09 Oct 2021 21:31:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1633815087; bh=9/TCSKn+NCT+e+g+sYWBqjjkmBNNuaApoQHtvc/7vbQ=; h=Received:Received:Received:Received:Date:From:To:Subject: Message-ID:MIME-Version:Content-Type; b=O6HVNOO3imFgE2LNPjHkequ/YUZi1HrgZoPsUzR/05faZDIAovBKp7hmmiw3sgId6 Ch+nnPqQKM48FguYseB+lJ1/Md0P2+bgTs5ffHQ8t9g686s1SaLqUwnY8ZMnTJdTE3 3lzz94XwDdMXAfhxP0/SMpXXNwoLdDYmqBltyJyY9Wya+ypbnvd476A/jKILQxvwNV 7DNRH6jT9aHf++Y8PJSsUe6NJwbdOgxn+xZrloooWpqObN0PyFEiAEh+15tSy4ZE+N BuNw7NSpuCjB5p6tr+lHcvF9CW2FW4me85MGQvaifDiI0uxCGDnbTcUtt9jDRulhs7 AQByn9D7bZXWQ== Received: from resomta-ch2-04v.sys.comcast.net ([69.252.207.100]) by resqmta-ch2-10v.sys.comcast.net with ESMTP id ZJivmicS4hBViZJwFmonSK; Sat, 09 Oct 2021 21:31:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=20190202a; t=1633815087; bh=9/TCSKn+NCT+e+g+sYWBqjjkmBNNuaApoQHtvc/7vbQ=; h=Received:Received:Received:Date:From:To:Subject:Message-ID: MIME-Version:Content-Type; b=UfGpLCw7Gmm8wOlyfbm3ITm4C0kXxItQSvsg/lC3OVGGaNM3aEdDjy+EVGp3KOMDY VqAVL1E+a2xyMI5idu3epn6whaGl5VfRtaPkgK7MBUawdUuU+PnJqwJegeZ6yyqGOZ R9Z0WQdOHxW0xweyugltX6ZDwwQ2zdOXHvvMUKgEwMAQ5lFoVyZ3xEGXvUSlYCtFd3 7PymNQxyFcwmItln8j/hD1p3c2EmBrCuRQUI70Jion2y64QVtBNObuN2atbKeoRzxE K0Zrs6sACagssXequyDnQCuMvo9ozWg6HXYnrJ9hHUcXcBbFxL+ROXwB1mJTpeAKAE K9+ggwn5Y4fXw== Received: from shrew ([66.30.144.167]) by resomta-ch2-04v.sys.comcast.net with ESMTPA id ZJvvmYBnq7ofdZJwEmgmsW; Sat, 09 Oct 2021 21:31:27 +0000 X-Xfinity-VAAS: gggruggvucftvghtrhhoucdtuddrgedvtddrvddtvddgudeitdcutefuodetggdotefrodftvfcurfhrohhfihhlvgemucevohhmtggrshhtqdftvghsihdpqfgfvfdppffquffrtefokffrnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpehrihhruceorhhirhgrnhhssegtohhmtggrshhtrdhnvghtqeenucggtffrrghtthgvrhhnpedugfdvffejtdekhfegleeujeekhfeigefhfeeugeeugfevjeeutdfhveegfffghfenucfkphepieeirdeftddrudeggedrudeijeenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhephhgvlhhopehshhhrvgifpdhinhgvthepieeirdeftddrudeggedrudeijedpmhgrihhlfhhrohhmpehrihhrrghnshestghomhgtrghsthdrnhgvthdprhgtphhtthhopehtghhlsehsshhsrdhpghhhrdhprgdruhhspdhrtghpthhtoheprhhirhgrnhhssegtohhmtggrshhtrdhnvghtpdhrtghpthhtoheplhgruhhrvghniidrrghlsggvsegthigsvghrthgvtgdrrghtpdhrtghpthhtohepphhgshhqlhdqughotghssehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrgh X-Xfinity-VMeta: sc=-100.00;st=legit Received: from rir by shrew with local (Exim 4.92) (envelope-from ) id 1mZJvv-0005ou-7f; Sat, 09 Oct 2021 17:31:07 -0400 Date: Sat, 9 Oct 2021 17:31:07 -0400 From: rir To: Tom Lane Cc: rir , Laurenz Albe , pgsql-docs@lists.postgresql.org Subject: Re: small patch Message-ID: <20211009213107.z3ffgqorqmbwqabp@localhost> References: <20211001163938.ifg4ayrsjwd7r6zr@localhost> <1c0eefa304434f67fd6a5a9d3f420d59ac74623a.camel@cybertec.at> <20211007033905.pmsg5qnyqceepfva@localhost> <9f703511c57d6bb0f44f9a968414869854ae50ea.camel@cybertec.at> <20211007200612.rkxxgeorw6w4fpjp@localhost> <175281.1633638256@sss.pgh.pa.us> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <175281.1633638256@sss.pgh.pa.us> User-Agent: NeoMutt/20180716 List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Oct 07, 2021 at 04:24:16PM -0400, Tom Lane wrote: > rir writes: > > On Thu, Oct 07, 2021 at 07:58:47AM +0200, Laurenz Albe wrote: > >> Can you think of a way to modify the syntax diagram so that it > >> expresses that and still remains comprehensible? > > > For myself, > > 'FETCH [ [ FROM | IN ] ] ' > > clearly indicates that 'direction' is optional. > > FETCH FROM cursor_name > > which in fact is legal. I think however that we could make it read > > FETCH [ ] [ FROM | IN ] ' > > and have a correct description without requiring > to be allowed to be empty. > BTW, as it stands, the diagram is ambiguous > because there are two ways to parse > > FETCH cursor_name > > ... is present but empty, or omitted altogether? I am confident you know what you mean, but I don't. At the _parsing_ stage how is any distinction between emptiness and omission? I can correct the patch to reflect the rightness of FETCH [ ] [ FROM | IN ] in the sgml file and at least one misquote I have found. Not being here that often, I will wait to see this conversation resolve. Rob