Reject "ALTER DATABASE/USER ... RESET foo" with invalid GUC name.

If the database or user had no entry in pg_db_role_setting,
RESET silently did nothing --- including not checking the
validity of the given GUC name.  This is quite inconsistent
and surprising, because you *would* get such an error if there
were any pg_db_role_setting entry, even though it contains
values for unrelated GUCs.

While this is clearly a bug, changing it in stable branches seems
unwise.  The effect will be that some ALTER commands that formerly
were no-ops will now be errors, and people don't like that sort of
thing in minor releases.

Author: Vitaly Davydov <v.davydov@postgrespro.ru>
Reviewed-by: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/30783e-68c28a00-9-41004480@130449754

src/backend/catalog/pg_db_role_setting.c

@@ -151,6 +151,15 @@ AlterSetting(Oid databaseid, Oid roleid, VariableSetStmt *setstmt)
 
 		CatalogTupleInsert(rel, newtuple);
 	}
+	else
+	{
+		/*
+		 * RESET doesn't need to change any state if there's no pre-existing
+		 * pg_db_role_setting entry, but for consistency we should still check
+		 * that the option is valid and we're allowed to set it.
+		 */
+		(void) GUCArrayDelete(NULL, setstmt->name);
+	}
 
 	InvokeObjectPostAlterHookArg(DbRoleSettingRelationId,
 								 databaseid, 0, roleid, false);