Re: illegal sort order - Mailing list pgsql-general

From Andrus
Subject Re: illegal sort order
Date
Msg-id db2s4b$2sf7$1@news.hub.org
Whole thread Raw
In response to Re: illegal sort order  ("Magnus Hagander" <mha@sollentuna.net>)
List pgsql-general
> Unicode is not currently supported when the server runs on Win32, see
> http://www.postgresql.org/docs/faqs.FAQ_windows.html#2.6. You'll need to
> pick a different encoding if you need locale-aware sorting.

I need to upsize tables from other dbms. This dbms does not support unicode.
I have tables which contain estonian language characters in one column
(using windows-1257 encoding) and russian langugage characters in other
column (using windows-1251 encoding) as single byte characters.
I use Postgres through ODBC.

I tried the following encodings for upsize this table with the following
results:

SQL_ASCII - non ascii characters are converted to question marks. This is
problably by ODBC driver since pgAdmin shows them.

LATIN1, LATIN4 - some characters cause error if I try to upsize my data to
Postgres (I use odbc for upsize).

If unicode is not working, I need fully transparent access through ODBC: all
bytes in range 32 .. 255 must be stored in unmodified form in CHARACTER and
TEXT fields and returned in unmodified form to my ODBC client.
This does not allow UPPER() function to work but at least sorting is
somewhat meaningful (when sorted by unsigned binary values.)

Unfortunately it seems that ODBC driver replaces some charactes to question
marks in case on SQL_ASCII .
 So I need SQL_UNSIGNED_BINARY  or SQL_TRANSPARENT encoding.
I tried to use binary data types insted of char and text types but pgADMIN
show them as octal strings.
I have no idea, meybe it is possible configure or modify odbc driver. I
looked into odbc drivers sources but havent found place which converts
chars>0x80 to question marks.

Any idea ?

When fixed unicode version (8.1?) will be available ?

Andrus.



pgsql-general by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: NTFS partition autodetection during instalation
Next
From: Roman Neuhauser
Date:
Subject: 7.4.7: strange planner decision