On 04 May 2001 15:44:23 -0400, Tom Lane wrote:
Back from the weekend with sunburn (very important sign that it has stopped
raining here on the west of Europe)
All this does
is move the problem from being one that non-english countries have to
being one where it is a non-english
[ thread renamed and cross-posted to pghackers, since this isn't only
about JDBC anymore ]
Barry Lind [EMAIL PROTECTED] writes:
The basic issue I have it that the server is providing an API to the
client to get the character encoding for the database and that API can
report incorrect
On Thu, 3 May 2001, Barry Lind wrote:
With regards to your specific problem, my guess is that you haven't
created you database with the proper character set for the data you are
storing in it. I am guessing you simply used the default SQL Acsii
character set for your created database and
Barry Lind [EMAIL PROTECTED] writes:
With regards to your specific problem, my guess is that you haven't
created you database with the proper character set for the data you are
storing in it. I am guessing you simply used the default SQL Acsii
character set for your created database and
On 04 May 2001 11:40:48 -0400, Tom Lane wrote:
I fought with this for a few days. The solution is to dump the database
and create a new database with the correct encoding.
MULTIBYTE is not neccesary I just set the type to LATIN1 and it works
fine.
But a non-MULTIBYTE backend doesn't
On 04 May 2001 10:29:50 -0400, Tom Lane wrote:
With regards to your specific problem, my guess is that you haven't
created you database with the proper character set for the data you are
storing in it. I am guessing you simply used the default SQL Acsii
character set for your created
On 04 May 2001 11:40:48 -0400, Tom Lane wrote:
But a non-MULTIBYTE backend doesn't even have the concept of setting
the encoding --- it will always just report SQL_ASCII.
What kind of error message does createdb -E LATIN1 give on a non
MULTIBYTE backend?
Maybe there needs to be a note
Tony Grant [EMAIL PROTECTED] writes:
What kind of error message does createdb -E LATIN1 give on a non
MULTIBYTE backend?
$ createdb -E LATIN1 foo
/home/postgres/testversion/bin/createdb[143]:
/home/postgres/testversion/bin/pg_encoding: not found.
createdb: LATIN1 is not a valid encoding
Tony Grant wrote:
On 04 May 2001 11:40:48 -0400, Tom Lane wrote:
But a non-MULTIBYTE backend doesn't even have the concept of setting
the encoding --- it will always just report SQL_ASCII.
What kind of error message does createdb -E LATIN1 give on a non
MULTIBYTE backend?
Maybe
Barry Lind [EMAIL PROTECTED] writes:
Now it is an easy change in the jdbc code to use LATIN1 when the server
reports SQL_ASCII, but I really dislike hardcoding support that only
works in english speaking countries and Western Europe.
What's wrong with that? It won't be any more broken for
Since Java uses unicode (ucs2) internally for all Strings, the jdbc code
always needs to do character set conversions for all strings it gets
from the database. In the 7.0 drivers this was done by assuming the
database was using the same character set as the default on the client,
which is
11 matches
Mail list logo
