Re: COPY support in pgsql-jdbc driver
От | Barry Lind |
---|---|
Тема | Re: COPY support in pgsql-jdbc driver |
Дата | |
Msg-id | 3D120CD5.9070401@xythos.com обсуждение исходный текст |
Ответ на | Re: COPY support in pgsql-jdbc driver (Michael Adler <adler@glimpser.org>) |
Список | pgsql-jdbc |
Sam Varshavchik wrote: > Barry Lind writes: > >> Sam Varshavchik wrote: >> >>> What's being dumped and reloaded here is a byte-stream >>> (InputStream/OutputStream), not a character-stream (Reader/Writer). >>> Presumably, the only thing that's ever going to be reloaded >>> something that was dumped previously, so no conversions are necessary. >> >> >> This is not correct. The data coming from the server is a stream of >> characters in the character encoding of the server. This character >> encoding may be different than the client character encoding, and >> therefore character set conversions are necessary. Lets say for >> example the database is running with UTF-8 as it's character set, >> thus the output of the copy will be UTF-8 encoded. If the client is >> running Latin1 then there will be a missmatch and all 8bit characters >> will be interpreted incorrectly by the client. Character set >> conversion is necessary in this case. > > > That only matters if you actually want to do something with the dumped > data. If all you want is to be able to reload it later, why bother > converting charset A to B, only to have it converted from B to A later? True, but if you want to look at the data in an editor you might like it to be in a character set you can view, also if you are going to reload the data through a different client (i.e. psql) you won't easily be able to as it will assume the client encoding. I said earlier that if the client encoding = server encoding this should be a noop. So you would always have the ability to have a higher level of performance by specifying the same encoding as the server. I also suggested that there be a method that didn't take an encoding which would use a default encoding. My recomendation was that the default be the default encoding for the running jvm, but it could default to the same encoding as the server. However since all the jdk methods that I am aware of which have an optional encoding argument default to the jvm encoding, I think it would be confusing to do something different here. But I could be convinced otherwise. thanks, --Barry
В списке pgsql-jdbc по дате отправления: