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 <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1mYZwI-0000Ec-5Q
	for pgsql-docs@arkaria.postgresql.org; Thu, 07 Oct 2021 20:24:26 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-docs-owner+archive@lists.postgresql.org>)
	id 1mYZwG-0007IA-Ct
	for pgsql-docs@arkaria.postgresql.org; Thu, 07 Oct 2021 20:24:24 +0000
Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1mYZwG-0007I2-6j
	for pgsql-docs@lists.postgresql.org; Thu, 07 Oct 2021 20:24:24 +0000
Received: from sss.pgh.pa.us ([66.207.139.130])
	by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <tgl@sss.pgh.pa.us>)
	id 1mYZwE-0006PK-79
	for pgsql-docs@lists.postgresql.org; Thu, 07 Oct 2021 20:24:23 +0000
Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1])
	by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 197KOGNn175282;
	Thu, 7 Oct 2021 16:24:16 -0400
From: Tom Lane <tgl@sss.pgh.pa.us>
To: rir <rirans@comcast.net>
cc: Laurenz Albe <laurenz.albe@cybertec.at>, pgsql-docs@lists.postgresql.org
Subject: Re: small patch
In-reply-to: <20211007200612.rkxxgeorw6w4fpjp@localhost>
References: <20211001163938.ifg4ayrsjwd7r6zr@localhost>
 <1c0eefa304434f67fd6a5a9d3f420d59ac74623a.camel@cybertec.at>
 <20211007033905.pmsg5qnyqceepfva@localhost>
 <9f703511c57d6bb0f44f9a968414869854ae50ea.camel@cybertec.at>
 <20211007200612.rkxxgeorw6w4fpjp@localhost>
Comments: In-reply-to rir <rirans@comcast.net>
	message dated "Thu, 07 Oct 2021 16:06:12 -0400"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <175280.1633638256.1@sss.pgh.pa.us>
Date: Thu, 07 Oct 2021 16:24:16 -0400
Message-ID: <175281.1633638256@sss.pgh.pa.us>
List-Id: <pgsql-docs.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-docs@lists.postgresql.org>
List-Owner: <mailto:pgsql-docs-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-docs>
Archived-At: 
 <https://www.postgresql.org/message-id/175281.1633638256%40sss.pgh.pa.us>
Precedence: bulk

rir <rirans@comcast.net> 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 [ <direction> [ FROM | IN ] ] <cursor_name>'
> clearly indicates that 'direction' is optional.

Right, but if we don't say that <direction> can be
empty, then this diagram disallows

	FETCH FROM cursor_name

which in fact is legal.  I think however that we could make it read

	FETCH [ <direction> ] [ FROM | IN ] <cursor_name>'

and have a correct description without requiring <direction>
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 <direction> present but empty, or omitted altogether?

			regards, tom lane