Re: String comparison problem in select - too many results

Поиск
Список
Период
Сортировка
От Durumdara
Тема Re: String comparison problem in select - too many results
Дата
Msg-id CAEcMXhnK=_Hmh5x4c_UeGLjZt-xCqRigYOuAGmGvKvYWmg4gyQ@mail.gmail.com
обсуждение исходный текст
Ответ на String comparison problem in select - too many results  (Durumdara <durumdara@gmail.com>)
Список pgsql-general
Dear Peter and Francisco!


Firstly: sorry for name change. I might read too many about Totti or I was listening too many "Vamos a la playa" spanitaliano disco... :-) :-) :-)

To better understand my problem I write about the background.
We used different database engine "before" PG, and more codes based on that SQL.
Because now only 70-80%% migrated, we need to preserve the compatibility with older database engine.
This run on Windows, and it uses the local collation order (ANSI: the basic ASCII extended with HUN characters. Like ISO-8859-2, or Windows1250).
It uses Windows comparison, so it doesn't matter that client sort or the server - in Hungarian machines it's same (AnsiCompareText/Str).
We dont't need to worry about filters/orders.

All ASCII characters preserved in sort, but Hungarians inserted between ASCII...
English: A, B, C, D, E, F,
Hungarian: A, Á, B, C, D, E, É, F

The data export works same in MS Excel or Libreoffice. The filters are same.

I supposed that HU_HU collation mostly similar.

The whole thing is important in row filtering, not in order. For sort data we can use Devexpress grids.

But the filters must be same. We used many range filters in text fieds. 
With older engine we can safely search ranges with "Á16-00023", "18343843/BÉR" values, the result row number is same in programme side and f. e. in Excel side.

I didn't understand what a hell caused this problem in PG side, what I did wrong.
This is why I showed many demonstrations, because I wanted to understand. The simulations points to "symbol removal".

Yes, we may handle these problems, but we need to construct "compatible" SQL, or we need to make different solution in PG side.
This would cause "bugs" in the working applications, and make difference between two products.

The C collation is good for only numbered fields. 
Splitting to substring and order on them is also good in this example.
But for special accents (, "ű", "ó", "ő", etc) we need to use different solution...
And the text fields are free, so "/" is only one symbol they can use.

Thank you for your instructions, help, and "flame"... :-)

Have a nice day for you!

dd



В списке pgsql-general по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Missing WAL file after running pg_rewind
Следующее
От: Guillaume Lelarge
Дата:
Сообщение: Re: Update blocking another update