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 1pzxsJ-0006ml-Lx for pgsql-hackers@arkaria.postgresql.org; Fri, 19 May 2023 11:02:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pzxsH-0001xN-Qr for pgsql-hackers@arkaria.postgresql.org; Fri, 19 May 2023 11:02:17 +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 1pzxsG-0001x6-KN for pgsql-hackers@lists.postgresql.org; Fri, 19 May 2023 11:02:17 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1pzxsB-000f1d-0q for pgsql-hackers@lists.postgresql.org; Fri, 19 May 2023 11:02:15 +0000 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 84DE15C0046; Fri, 19 May 2023 07:02:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Fri, 19 May 2023 07:02:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t=1684494129; x= 1684580529; bh=0nO8ApQ2TCGVl44WzvJrbFPsPVQzVqlQwpTHIC8/V9o=; b=h q8T+y5Pf/DMcNFLr91WgHSXPlOkR4VHVe0GyUII9BgtaAMxHx3RmumRVrvKTSvzT CBC25fwZBA4ClEgH0sYxy5w7OXIRjbkUXtSmUwp4X/TGPB6ZzavrGBsnZAT3aq0v 7K4k1VmLD+T++MnmewJ4wr1JbFCx7TMV7qbw3MvHTlstC7mR9tZtCBEVdfP/eMo7 rj1hdBXiKRthEnWVeKjGi3uYzRuP7ZVn99IWrAcqj5HSi6AywQwP1nVnmnnOABKp 4HC6MtnVl99ztPiqHda/+RK+YaG6eLTcUYVIqU8EMbhvD/fq/Lrv1+fDPFNZkJzL UAMhsXH+b/EGVY4UqXfEQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeeihedgfeeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkgggtugfgjgesmhekreertddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepudelkeekgfdttdettdekgfduvdeiffelteegjeeihfet heekveeftedtuddvhfeunecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Feedback-ID: ia2694551:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 19 May 2023 07:02:08 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id E316438B; Fri, 19 May 2023 13:02:05 +0200 (CEST) Date: Fri, 19 May 2023 13:02:05 +0200 From: Alvaro Herrera To: Andrew Dunstan Cc: Platon Pronko , PostgreSQL Hackers Subject: Re: very long record lines in expanded psql output Message-ID: <20230519110205.updpbjiuqgbox6gp@alvherre.pgsql> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="7dltxkhfrj6skipq" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <46f0313e-2097-2ad6-8965-45af62af3243@dunslane.net> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --7dltxkhfrj6skipq Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit On 2022-Jul-25, Andrew Dunstan wrote: > Committed. There were a couple of bits missing, which I filled in, and I > changed the behaviour when the option is given without an argument, so > that instead of resetting it the current value is shown, similarly to > how most pset options work. I was translating the new messages introduced by this commit, and decided to unify them. While doing so, I notice that the feature misbehaves when you give it a string value that doesn't match any valid value: it just resets the value to 0, which is entirely the wrong thing. For other settings, we first verify that the given value is valid, and only then we change the setting. So I came up with the attached. While at it, I noticed that we have other uses of atoi() there, most notably pager_min_lines. My first impulse was to just to do the same as for xheader_width, namely to test whether the atoid result is zero, and not change in that case. But then I noticed we're already using variables.c facilities, so I decided to do likewise; this results in simpler code. So we're now stricter, because variables.c rejects trailing junk after the number. (123asd was previously parsed as 123, now it's an error.) There remain atoi uses in this code, and aside from the atoi()-induced behavior of making any non-number input set it to 0, it does stuff like =# \pset border 65538asd Border style is 2. because border style is short int, so this value overflows it. Same happens with 'columns'. However, this is all very old code and nobody seems to have complained. -- Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/ "¿Cómo puedes confiar en algo que pagas y que no ves, y no confiar en algo que te dan y te lo muestran?" (Germán Poo) --7dltxkhfrj6skipq Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-Tweak-xheader_width-input-parsing.patch" From 5eb799984252cf231064d6d174e13d63880577df Mon Sep 17 00:00:00 2001 From: Alvaro Herrera Date: Fri, 19 May 2023 12:58:54 +0200 Subject: [PATCH] Tweak xheader_width input parsing Don't throw away the previous value when an invalid value is proposed. Also, change the error messages to not need separate translations. While at it, change pager_min_lines to also avoid changing the setting when an invalid value is given. --- src/bin/psql/command.c | 20 ++++++++++++-------- 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/src/bin/psql/command.c b/src/bin/psql/command.c index 607a57715a3..07c5f026b9b 100644 --- a/src/bin/psql/command.c +++ b/src/bin/psql/command.c @@ -4521,13 +4521,16 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet) popt->topt.expanded_header_width_type = PRINT_XHEADER_PAGE; else { - popt->topt.expanded_header_width_type = PRINT_XHEADER_EXACT_WIDTH; - popt->topt.expanded_header_exact_width = atoi(value); - if (popt->topt.expanded_header_exact_width == 0) + int intval = atoi(value); + + if (intval == 0) { pg_log_error("\\pset: allowed xheader_width values are full (default), column, page, or a number specifying the exact width."); return false; } + + popt->topt.expanded_header_width_type = PRINT_XHEADER_EXACT_WIDTH; + popt->topt.expanded_header_exact_width = intval; } } @@ -4660,8 +4663,9 @@ do_pset(const char *param, const char *value, printQueryOpt *popt, bool quiet) /* set minimum lines for pager use */ else if (strcmp(param, "pager_min_lines") == 0) { - if (value) - popt->topt.pager_min_lines = atoi(value); + if (value && + !ParseVariableNum(value, "pager_min_lines", &popt->topt.pager_min_lines)) + return false; } /* disable "(x rows)" footer */ @@ -4727,11 +4731,11 @@ printPsetInfo(const char *param, printQueryOpt *popt) else if (strcmp(param, "xheader_width") == 0) { if (popt->topt.expanded_header_width_type == PRINT_XHEADER_FULL) - printf(_("Expanded header width is 'full'.\n")); + printf(_("Expanded header width is '%s'.\n"), "full"); else if (popt->topt.expanded_header_width_type == PRINT_XHEADER_COLUMN) - printf(_("Expanded header width is 'column'.\n")); + printf(_("Expanded header width is '%s'.\n"), "column"); else if (popt->topt.expanded_header_width_type == PRINT_XHEADER_PAGE) - printf(_("Expanded header width is 'page'.\n")); + printf(_("Expanded header width is '%s'.\n"), "page"); else if (popt->topt.expanded_header_width_type == PRINT_XHEADER_EXACT_WIDTH) printf(_("Expanded header width is %d.\n"), popt->topt.expanded_header_exact_width); } base-commit: 0b8ace8d773257fffeaceda196ed94877c2b74df -- 2.39.2 --7dltxkhfrj6skipq--