Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tJiMQ-004kb5-0R for pgsql-bugs@arkaria.postgresql.org; Sat, 07 Dec 2024 00:07:50 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tJiMM-00EU2M-Cz for pgsql-bugs@arkaria.postgresql.org; Sat, 07 Dec 2024 00:07:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tJiMM-00EU2E-4Z for pgsql-bugs@lists.postgresql.org; Sat, 07 Dec 2024 00:07:47 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tJiMK-001QnX-8A; Sat, 07 Dec 2024 00:07:46 +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 4B707f0p3066302; Fri, 6 Dec 2024 19:07:41 -0500 From: Tom Lane To: Tatsuo Ishii cc: koichi.dbms@gmail.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows In-reply-to: <20241207.081412.2050532354647835961.ishii@postgresql.org> References: <2751825.1733464455@sss.pgh.pa.us> <20241206.154248.1191531539866262856.ishii@postgresql.org> <2840430.1733510664@sss.pgh.pa.us> <20241207.081412.2050532354647835961.ishii@postgresql.org> Comments: In-reply-to Tatsuo Ishii message dated "Sat, 07 Dec 2024 08:14:12 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3066300.1733530061.1@sss.pgh.pa.us> Date: Fri, 06 Dec 2024 19:07:41 -0500 Message-ID: <3066301.1733530061@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Tatsuo Ishii writes: > I think the encoding we need to supply to canonicalize_path() is not > necessarily the same as client_encoding. For example we could set > client_encoding to UTF-8 but use a file which has Shift-JIS encode > file name. I think what we really need to supply to > canonicalize_path() is the "file system encoding", not > client_encoding. That was what I was thinking yesterday, but seems to me it could not really work to have client_encoding set to UTF-8 while you're trying to type an SJIS file name. Even if your terminal program doesn't mangle anything, it's likely that psqlscan.l will. I suppose if we think that's the situation, we could try to translate the file path names from UTF8 to SJIS. But that's a chunk of functionality that doesn't exist right now, plus I'm afraid it'd often make things worse not better. We don't have nearly as much certainty as we could wish about which encoding incoming data is in. regards, tom lane