Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-11 Thread Barry Lind
No this isn't a locale issue. This is a character set issue. Java is unicode based. Therefore it needs to convert data it receives from the server into unicode. In order to do this, it needs to know the character set that the server is sending back the data in. Locale issues like collatio

Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-10 Thread Bruce Momjian
Can I ask, isn't this the meaning if locale? Is the problem that we need locale capability in jdbc? We have a --enable-locale configure option. > > Is this a jdbc issue or a general backend issue? > > > > Bruce, > > > > I think the TODO item should be: > > > > Ability to set character s

Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-09 Thread Barry Lind
General backend issue. --Barry Bruce Momjian wrote: > Is this a jdbc issue or a general backend issue? > > > >>Bruce, >> >>I think the TODO item should be: >> >>Ability to set character set for a database without multibyte enabled >> >>Currently createdb -E (and the corresponding create datab

Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-09 Thread Bruce Momjian
Is this a jdbc issue or a general backend issue? > Bruce, > > I think the TODO item should be: > > Ability to set character set for a database without multibyte enabled > > Currently createdb -E (and the corresponding create database sql > command) only works if multibyte is enabled. Howev

Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-09 Thread Bruce Momjian
Added to TODO. > Bruce, > > I think the TODO item should be: > > Ability to set character set for a database without multibyte enabled > > Currently createdb -E (and the corresponding create database sql > command) only works if multibyte is enabled. However it is useful to > know which

Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-09 Thread Barry Lind
Bruce, I think the TODO item should be: Ability to set character set for a database without multibyte enabled Currently createdb -E (and the corresponding create database sql command) only works if multibyte is enabled. However it is useful to know which single byte character set is being us

Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-09 Thread Barry Lind
Rene, Two comments on your writeup about the problem: 1) Depending on version you will see different behavior: 7.0 - default client character set is used 7.1 - database character set is used (although it may be reported incorrectly as SQL_ASCII) 7.2 - database character set is used

Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-09 Thread Rene Pijlman
On Sun, 9 Sep 2001 10:24:32 -0400 (EDT), Bruce Momjian wrote: >I can add something if people agree there is an issue here. IMO the issue is twofold. Without multibyte compiled in: 1) the server cannot tell the client which single byte character encoding is being used, so a client like JDBC cann

Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-09 Thread Bruce Momjian
I can add something if people agree there is an issue here. > I've added a new section "Character encoding" to > http://lab.applinet.nl/postgresql-jdbc/, based on the > information from Dave and Barry. > > I haven't seen a confirmation from pgsql-hackers or Bruce yet > that this issue will be a

Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-09 Thread Rene Pijlman
I've added a new section "Character encoding" to http://lab.applinet.nl/postgresql-jdbc/, based on the information from Dave and Barry. I haven't seen a confirmation from pgsql-hackers or Bruce yet that this issue will be added to the Todo list. I'm under the impression that the backend developer

Re: [HACKERS] [JDBC] Troubles using German Umlauts with JDBC

2001-09-04 Thread Barry Lind
Rene, I would like to add one additional comment. In current sources the jdbc driver detects (through a hack) that the server doesn't have multibyte enabled and then ignores the SQL_ASCII return value and defaults to the JVM's character set instead of using SQL_ASCII. The problem boils down