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 1tKF2f-007dUQ-EG for pgsql-bugs@arkaria.postgresql.org; Sun, 08 Dec 2024 11:01:37 +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 1tKF2c-001DMx-DW for pgsql-bugs@arkaria.postgresql.org; Sun, 08 Dec 2024 11:01:35 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tKF2c-001DMn-4e for pgsql-bugs@lists.postgresql.org; Sun, 08 Dec 2024 11:01:35 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tKF2a-001eWD-Eb for pgsql-bugs@lists.postgresql.org; Sun, 08 Dec 2024 11:01:34 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=Content-Transfer-Encoding:Content-Type: Mime-Version:References:In-Reply-To:From:Subject:Cc:To:Message-Id:Date:Sender :Reply-To:Content-ID:Content-Description; bh=kMUwEJ2PLWF5tvMwzQQc7BJimlKtjkUuycuj32BQrTQ=; b=59U0BGzc1pB3Zrl/PD2kCppzOX xbTQAj9Tw/Wlgyfj2j3UFaAxzC7SmqFV9pO+gY6ogCuLDkWtwFFosjdFgvsmKL5KksHe2xjBmBkM+ FYwB37hjIcz0zemByEfK57jbesP0llTMtDQjgF21F0yyzzH3r5LMEFbtRXkSnB9e8gp3hZNOnQXmJ x6CnDMDScAvbaYGguPaJXmqZH+B9SR679OB1rcIgLyEhEYW32dwY/UqRk7sTKK84h+HJNYrsKlNiG G3OtHJibuFEtX2psl0Y8N82TWPPEJqcphKU1qYBb2k/21jVf7F6zXKoTyKR+yuvrH0hyycTqLcNpU qTUPPOYA==; Received: from [2409:11:4120:300:d108:e509:d471:d21b] (helo=localhost) by meldrar.postgresql.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (Exim 4.94.2) (envelope-from ) id 1tKF2T-0055bh-Nf; Sun, 08 Dec 2024 11:01:29 +0000 Date: Sun, 08 Dec 2024 20:01:18 +0900 (JST) Message-Id: <20241208.200118.410748201504579781.ishii@postgresql.org> To: tgl@sss.pgh.pa.us 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 From: Tatsuo Ishii In-Reply-To: <2850994.1733516077@sss.pgh.pa.us> References: <20241206.154248.1191531539866262856.ishii@postgresql.org> <2840430.1733510664@sss.pgh.pa.us> <2850994.1733516077@sss.pgh.pa.us> X-Mailer: Mew version 6.8 on Emacs 26.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Host-Lookup-Failed: Reverse DNS lookup failed for 2409:11:4120:300:d108:e509:d471:d21b (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > Another way, given that we only really need this to work for > SJIS, is to hard-wire the logic into path.c --- it's not like > pg_sjis_mblen is either long or likely to change. That's > ugly but would be a lot less invasive and safer to back-patch. > > I'm leaning a bit to the second way, mainly because of the > extern-relocation annoyance. +1. I believe the logic of detecting byte length in Shift-JIS will not be changed. Best reagards, -- Tatsuo Ishii SRA OSS K.K. English: http://www.sraoss.co.jp/index_en/ Japanese:http://www.sraoss.co.jp