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 1nFSnX-0006dn-PH for pgsql-hackers@arkaria.postgresql.org; Thu, 03 Feb 2022 03:28:39 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nFSnW-0005cF-Lu for pgsql-hackers@arkaria.postgresql.org; Thu, 03 Feb 2022 03:28:38 +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 ) id 1nFSnW-0005c6-Ct for pgsql-hackers@lists.postgresql.org; Thu, 03 Feb 2022 03:28:38 +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 ) id 1nFSnU-0005Ws-2v for pgsql-hackers@lists.postgresql.org; Thu, 03 Feb 2022 03:28:38 +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 2133SVwq147686; Wed, 2 Feb 2022 22:28:31 -0500 From: Tom Lane To: Andres Freund cc: pgsql-hackers@lists.postgresql.org, pgbf@twiska.com Subject: Re: psql tab completion versus Debian's libedit In-reply-to: <20220203021029.aw5ivy7u4us6msfm@alap3.anarazel.de> References: <960764.1643751011@sss.pgh.pa.us> <20220203021029.aw5ivy7u4us6msfm@alap3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Wed, 02 Feb 2022 18:10:29 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <147684.1643858911.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 02 Feb 2022 22:28:31 -0500 Message-ID: <147685.1643858911@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > I think this is caused by the feature flag detection being broken in the= meson > branch - unrelated to your commit - ending up with falsely believing tha= t none > of the rl_* variables exist (below for more on that aspect). > Do we care that the tests would fail when using a readline without any o= f the > rl_* variables? I don't know if those even exist. Hm, interesting. I reproduced this by #undef'ing HAVE_RL_COMPLETION_APPEND_CHARACTER in pg_config.h. It's not too surprising, because without that, we have no way to prevent readline from appending a space to a completion. In the test at hand, that causes two failures: 1. After we do "pub", we get "public. " not just "public."; and now, that is no longer part of the word-to-be-completed. That breaks the test because FROM is no longer the previous word but the one before that, so we won't try to do table completion. 2. After we do "tab", we normally get "tab1 ", but since no completion is attempted, we should get just "tab". But we get "tab " because the dummy-completion code at the bottom of psql_completion fails to suppress adding a space. In general, *any* failed completion would nonetheless append a space. Each of these is sufficiently bad to prompt user complaints, I think, but we've seen none. And I observe that every buildfarm animal reports having rl_completion_append_character. I conclude that there are no extant versions of readline/libedit that don't have rl_completion_append_character, so we could drop that configure test and save a cycle or two. regards, tom lane