From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | tgl(at)sss(dot)pgh(dot)pa(dot)us |
Cc: | koichi(dot)dbms(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows |
Date: | 2024-12-08 10:37:36 |
Message-ID: | 20241208.193736.1748337256420999108.ishii@postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2024-12-08 11:01:18 | Re: BUG #18735: Specific multibyte character in psql file path command parameter for Windows |
Previous Message | Tom Lane | 2024-12-07 17:49:45 | Re: FF3 vs MS Date/Time Template - ERROR: date/time field value out of range |