TL> Alex Guryanow <gav@nlr.ru> writes:
>> When pg-server is version 7.1.3 windows app works fine, but when
>> pg-server is version 7.4.6 or 8.0beta4 under certain conditions the
>> app receives strings with wrong lengths.
TL> Are both servers set up with the same database encoding?
I think the answer is yes. For both servers the command "initdb" was
executed only with parameter DATADIR. At the same time the locale is
set up to "ru_RU.cp1251".
But by creating the database I specify parameter "-E UNICODE" and
"psql -l" shows that the database is in UNICODE encoding. One
time I have forgotten to specify '-E UNICODE' by executing createdb
and windows app worked fine with 7.4.6
TL> (Is the 7.1
TL> server even compiled to support non-ASCII encodings?)
Here is the fragment of config.status from 7.1.3 source directory
./configure --prefix=/db/pgsql-713 --enable-locale --enable-multibyte --with-perl
>> But by executing the query
>> select volume, trim(number) from issue where mag_id = 25403;
>> the datagrid component (that displays query's results) contains in
>> second column values with length of 32769.
TL> If you try the same query in plain psql, what do you get?
I get all ok. For example, the query
select volume, length( trim( number ) ) from issue where mag_id = 25403;
shows in second column values from 5 to 7
TL> What is in
TL> the wrong-length value, exactly?
'N 1-2'
The appropriate "volume" column contains 'Evf. 120' where 'E' is 'E
with ascent' (I don't know how to write them in this letter). pg_dump
writes the following sequence of bytes (in hex-format) for this value:
C3 89 76 66 2E 20 31 32 30
and 'N 1-2' is
4E 20 31 2D 32
Best regards,
Alex
TL> regards, tom lane