Date: Sun, 08 Dec 2024 19:37:36 +0900 (JST)
Message-Id: <20241208.193736.1748337256420999108.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 <ishii@postgresql.org>
In-Reply-To: <3066301.1733530061@sss.pgh.pa.us>
References: <2840430.1733510664@sss.pgh.pa.us>
	<20241207.081412.2050532354647835961.ishii@postgresql.org>
	<3066301.1733530061@sss.pgh.pa.us>
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/20241208.193736.1748337256420999108.ishii%40postgresql.org>
Precedence: bulk

> 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.

Ok. So if the client encoding is not a "safe" encoding like Shift-JIS,
we have to use the same encoding for both the client encoding and the
file system encoding. I don't think this is an unreasonable
limitation.

> 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.

Yes. Also in PostgreSQL encoding conversion is extensible and the
feature is only available in backend.

Best reagards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp