Remove unnecessary grammar symbols

Started by Peter Eisentrautabout 5 years ago2 messages
#1Peter Eisentraut
peter.eisentraut@enterprisedb.com
1 attachment(s)

While doing the proverbial other things, I noticed that the grammar
symbols publication_name_list and publication_name_item are pretty
useless. We already use name_list/name to refer to publications in most
places, so getting rid of these makes things more consistent.

These appear to have been introduced by the original logical replication
patch, so there probably wasn't that much scrutiny on this detail then.

Attachments:

0001-Remove-unnecessary-grammar-symbols.patchtext/plain; charset=UTF-8; name=0001-Remove-unnecessary-grammar-symbols.patch; x-mac-creator=0; x-mac-type=0Download
From 311f3c7e40b47ace182f1ad5e39a6a12ae80d23c Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Thu, 3 Dec 2020 10:40:57 +0100
Subject: [PATCH] Remove unnecessary grammar symbols

Instead of publication_name_list, we can use name_list.  We already
refer to publications everywhere else by the 'name' or 'name_list'
symbols, so this only improves consistency.
---
 src/backend/parser/gram.y | 20 ++------------------
 1 file changed, 2 insertions(+), 18 deletions(-)

diff --git a/src/backend/parser/gram.y b/src/backend/parser/gram.y
index 61f0236041..5d343f3e0f 100644
--- a/src/backend/parser/gram.y
+++ b/src/backend/parser/gram.y
@@ -414,7 +414,6 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
 				relation_expr_list dostmt_opt_list
 				transform_element_list transform_type_list
 				TriggerTransitions TriggerReferencing
-				publication_name_list
 				vacuum_relation_list opt_vacuum_relation_list
 				drop_option_list
 
@@ -422,7 +421,6 @@ static Node *makeRecursiveViewSelect(char *relname, List *aliases, Node *query);
 %type <node>	group_by_item empty_grouping_set rollup_clause cube_clause
 %type <node>	grouping_sets_clause
 %type <node>	opt_publication_for_tables publication_for_tables
-%type <value>	publication_name_item
 
 %type <list>	opt_fdw_options fdw_options
 %type <defelt>	fdw_option
@@ -9512,7 +9510,7 @@ AlterPublicationStmt:
  *****************************************************************************/
 
 CreateSubscriptionStmt:
-			CREATE SUBSCRIPTION name CONNECTION Sconst PUBLICATION publication_name_list opt_definition
+			CREATE SUBSCRIPTION name CONNECTION Sconst PUBLICATION name_list opt_definition
 				{
 					CreateSubscriptionStmt *n =
 						makeNode(CreateSubscriptionStmt);
@@ -9524,20 +9522,6 @@ CreateSubscriptionStmt:
 				}
 		;
 
-publication_name_list:
-			publication_name_item
-				{
-					$$ = list_make1($1);
-				}
-			| publication_name_list ',' publication_name_item
-				{
-					$$ = lappend($1, $3);
-				}
-		;
-
-publication_name_item:
-			ColLabel			{ $$ = makeString($1); };
-
 /*****************************************************************************
  *
  * ALTER SUBSCRIPTION name ...
@@ -9572,7 +9556,7 @@ AlterSubscriptionStmt:
 					n->options = $6;
 					$$ = (Node *)n;
 				}
-			| ALTER SUBSCRIPTION name SET PUBLICATION publication_name_list opt_definition
+			| ALTER SUBSCRIPTION name SET PUBLICATION name_list opt_definition
 				{
 					AlterSubscriptionStmt *n =
 						makeNode(AlterSubscriptionStmt);
-- 
2.29.2

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Peter Eisentraut (#1)
Re: Remove unnecessary grammar symbols

Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:

While doing the proverbial other things, I noticed that the grammar
symbols publication_name_list and publication_name_item are pretty
useless. We already use name_list/name to refer to publications in most
places, so getting rid of these makes things more consistent.

+1. Strictly speaking, this reduces the set of keywords that you
can use as names here (since name is ColId, versus ColLabel in
publication_name_item). However, given the inconsistency with
other commands, I don't see it as an advantage to be more forgiving
in just one place. We might have problems preserving the laxer
definition anyway, if the syntaxes of these commands ever get
any more complicated.

regards, tom lane