Doc: improve description of plpgsql's FETCH and MOVE commands.

We were not being clear about which variants of the "direction"
clause are permitted in MOVE.  Also, the text seemed to be
written with only the FETCH/MOVE NEXT case in mind, so it
didn't apply very well to other variants.

Also, document that "MOVE count IN cursor" only works if count
is a constant.  This is not the whole truth, because some other
cases such as a parenthesized expression will also work, but
we want to push people to use "MOVE FORWARD count" instead.
The constant case is enough to cover what we allow in plain SQL,
and that seems sufficient to claim support for.

Update a comment in pl_gram.y claiming that we don't document
that point.

Per gripe from Philipp Salvisberg.

Discussion: https://postgr.es/m/172155553388.702.7932496598218792085@wrigleys.postgresql.org

1 files changed, 5 insertions, 5 deletions

diff --git a/src/pl/plpgsql/src/pl_gram.y b/src/pl/plpgsql/src/pl_gram.y
index a29d2dfacdd..97be9239e37 100644
--- a/src/pl/plpgsql/src/pl_gram.y
+++ b/src/pl/plpgsql/src/pl_gram.y
@@ -3219,11 +3219,11 @@ read_fetch_direction(void)
 	{
 		/*
 		 * Assume it's a count expression with no preceding keyword.
-		 * Note: we allow this syntax because core SQL does, but we don't
-		 * document it because of the ambiguity with the omitted-direction
-		 * case.  For instance, "MOVE n IN c" will fail if n is a variable.
-		 * Perhaps this can be improved someday, but it's hardly worth a
-		 * lot of work.
+		 * Note: we allow this syntax because core SQL does, but it's
+		 * ambiguous with the case of an omitted direction clause; for
+		 * instance, "MOVE n IN c" will fail if n is a variable, because the
+		 * preceding else-arm will trigger.  Perhaps this can be improved
+		 * someday, but it hardly seems worth a lot of work.
 		 */
 		plpgsql_push_back_token(tok);
 		fetch->expr = read_sql_expression2(K_FROM, K_IN,