Re: BUG #3453: Error on COPY TO/FROM 'non-ascii-path'
От | Hiroshi Saito |
---|---|
Тема | Re: BUG #3453: Error on COPY TO/FROM 'non-ascii-path' |
Дата | |
Msg-id | 060d01c7c846$634439b0$c601a8c0@HP22720319231 обсуждение исходный текст |
Ответ на | BUG #3453: Error on COPY TO/FROM 'non-ascii-path' ("ITAGAKI Takahiro" <itagaki.takahiro@oss.ntt.co.jp>) |
Список | pgsql-bugs |
Hi. >> I think that it is use restrictions now....This is not a BUG. > > Sure, but I'd like to notice that we don't pay attention about > mismatch of PG and OS encodings. Ah, yes.. I also agree that it has a user's confusion. > >> In Japan, use is restricted by the reason referred to as that server >> encoding does not support all now. Then, It is Shift-jis encoding... > > We don't have to support SJIS as a server encoding for this purpose. > We just need to have converter function like convert_server_to_os() > and use it when the path might include non-ascii characters. > We can skip the function in usual file operations, for example, opening > a relation file, because paths under $PGDATA consists of only ascii > characters. We can minimize the performance impact from the conversion. > > One problem is that we might not have enough information about OS > encodings, at least we cannot determine it using a portable method. > If we would know the native encoding, convertion itself will be easy. > For example, we can use convert('path-for-copy', server-encoding, 'SJIS') > in Japanese version of Windows. Um, It has a means to avoid now as surely you suggest...... Do you mean judgment material by the server side? Sorry, I don't have a good idea now.... Regards, Hiroshi Saito
В списке pgsql-bugs по дате отправления: