Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1if4x5-00068E-F7 for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Dec 2019 16:35:03 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1if4x3-0001W5-UN for pgsql-hackers@arkaria.postgresql.org; Wed, 11 Dec 2019 16:35:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1if4x3-0001Vw-Ko for pgsql-hackers@lists.postgresql.org; Wed, 11 Dec 2019 16:35:01 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1if4x1-00047V-0M for pgsql-hackers@lists.postgresql.org; Wed, 11 Dec 2019 16:35:01 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.4/8.14.4) with ESMTP id xBBGYpl8017380; Wed, 11 Dec 2019 11:34:51 -0500 From: Tom Lane To: Robert Haas cc: Alvaro Herrera , PostgreSQL Hackers , steven.winfield@cantabcapital.com Subject: Re: BUG #16059: Tab-completion of filenames in COPY commands removes required quotes In-reply-to: References: <20191211150637.GA21159@alvherre.pgsql> <15389.1576079550@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Wed, 11 Dec 2019 10:57:30 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17378.1576082091.1@sss.pgh.pa.us> Date: Wed, 11 Dec 2019 11:34:51 -0500 Message-ID: <17379.1576082091@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk Robert Haas writes: > On Wed, Dec 11, 2019 at 10:52 AM Tom Lane wrote: >> I think it's Debian's problem, not ours, if that doesn't work. It is >> not unreasonable for a package to probe existence of a library function >> at configure time. It's up to them to make sure that the headers match >> the actual library. > That seems like an unhelpful attitude. Debian is a mainstream > platform, and no doubt feels that they have important reasons for what > they are doing. Nonetheless, if they're doing that, it's *their* bug not ours when the run-time library fails to match what was supplied to compile against. I think it would fall to them to patch either libedit or readline to make those two agree. This is not different in any way from the expectation that a platform supply a libc whose ABI is stable. In any case, this discussion is a bit hypothetical isn't it? If I understand correctly, your concern is that the proposed patch might fail to take advantage of functionality that actually might be present at runtime. So what? It's no worse than before. More, it's likely that there are other similar losses of functionality already in our code and/or other peoples'. Debian bought into that tradeoff, not us. regards, tom lane