Re: String comparison problem in select - too many results

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