Re: [GENERAL] Wrong string length from unicode database in Borland's app

TL> Alex Guryanow <gav(at)nlr(dot)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