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 1ir2fw-0001DD-2e for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Jan 2020 16:34:48 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1ir2fu-0000o5-Sh for pgsql-hackers@arkaria.postgresql.org; Mon, 13 Jan 2020 16:34:46 +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 1ir2ft-0000ny-WC for pgsql-hackers@lists.postgresql.org; Mon, 13 Jan 2020 16:34:46 +0000 Received: from out1-smtp.messagingengine.com ([66.111.4.25]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ir2fq-000507-C2 for pgsql-hackers@lists.postgresql.org; Mon, 13 Jan 2020 16:34:45 +0000 Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 16DB52211A; Mon, 13 Jan 2020 11:34:40 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Mon, 13 Jan 2020 11:34:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=C98s/+YqS5U+d1BrnLf+PrJqjfmVH+I6xjFdlhYOr qE=; b=knEcmnlLLoGSacndccwRmygUiIDprbJhHzDISLFyG1cH+5Wi7jZT8ETQn n1SELWAo24kJ1NdA7jMqVpnoSmbm4Vs0sDf7354JFfVWCWz5KWyuqmDMkov5B7UG 86j3UIwGsstOl9ShcflHNwZ2qUuiGHxee8ZR6GIoQzSycgKb6qjsUBR6hR3zNC6a j7iumSnKG1qPAJcrUfr3KTDAQDjwrwXi/H111KFzsDFfuE5fwMAQxnZA+QkTZIpd xuXXEuq5vSos0r/N1UmcNfepGvLz3MKU8p1BVsP1MPnuSRMzFi4Tf9/11g+lBPry R80bSgqtkznmJ5RcmY8E01+85DKIg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrvdejtddgkeekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpefuvfhfhfhokffffgggjggtgfesth ejredttdefheenucfhrhhomheprfgvthgvrhcugfhishgvnhhtrhgruhhtuceophgvthgv rhdrvghishgvnhhtrhgruhhtsedvnhguqhhurggurhgrnhhtrdgtohhmqeenucffohhmrg hinhepvdhnughquhgrughrrghnthdrtghomhenucfkphepleefrddvgeefrdduieefrddv vdejnecurfgrrhgrmhepmhgrihhlfhhrohhmpehpvghtvghrrdgvihhsvghnthhrrghuth esvdhnughquhgrughrrghnthdrtghomhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from april.pezone.net (p5df3a3e3.dip0.t-ipconnect.de [93.243.163.227]) by mail.messagingengine.com (Postfix) with ESMTPA id BCBCE8005C; Mon, 13 Jan 2020 11:34:38 -0500 (EST) Subject: Re: BUG #16059: Tab-completion of filenames in COPY commands removes required quotes To: Tom Lane References: <16059-8836946734c02b84@postgresql.org> <30313.1572729260@sss.pgh.pa.us> <1628.1572820800@sss.pgh.pa.us> <6ccd23e4-ce58-c2b5-39a1-801a9937ae86@2ndquadrant.com> <12699.1578058657@sss.pgh.pa.us> <32307.1578290788@sss.pgh.pa.us> Cc: pgsql-hackers@lists.postgresql.org, steven.winfield@cantabcapital.com From: Peter Eisentraut Organization: 2ndQuadrant Message-ID: <1ed54e8f-d84e-bfbe-ffad-890015e12735@2ndquadrant.com> Date: Mon, 13 Jan 2020 17:34:37 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <32307.1578290788@sss.pgh.pa.us> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020-01-06 07:06, Tom Lane wrote: > Hence, the attached revision only forces quoting in a SQL COPY > command, or if the user already typed a quote. Yes, that seems better. Users tend to not like if tab completion messes with what they have already typed unless strictly necessary. The file name completion portion of this patch seems to work quite well now. I have found a weird behavior with identifier quoting, which is not the subject of this patch, but it appears to be affected by it. The good thing is that the new code will behave sensibly with select * from "pg_cl which the old code didn't offer anything on. The problem is that if you have create table "test""1" (a int); then the new code responds to select * from "te by making that select * from "te" whereas the old code curiously handled that perfectly. Neither the old nor the new code will produce anything from select * from te -- Peter Eisentraut http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services