Dear David!
I tried in in different servers, different databases.
1.) Windows local PG: LC_COLLATE = 'Hungarian_Hungary.1250' - ok.
2.) Linux remote PG: LC_CTYPE = 'en_US.UTF-8' - also wrong!!! - UTF problem???
3.) Forcing C collation: - ok
4.) Replace '/' to 'A': - ok
replace('18/0113', '/', 'A') > replace('180/2010', '/', 'A'),
replace('18/0113', '/', 'A') < replace('180/2010', '/', 'A'),
replace('18/0212', '/', 'A') > replace('180/2010', '/', 'A'),
replace('18/0212', '/', 'A') < replace('180/2010', '/', 'A')
5.) Replace '/' to space: - wrong
6.) Replace '/' to empty string: wrong
replace('18/0113', '/', '') > replace('180/2010', '/', ''),
replace('18/0113', '/', '') < replace('180/2010', '/', ''),
replace('18/0212', '/', '') > replace('180/2010', '/', ''),
replace('18/0212', '/', '') < replace('180/2010', '/', '')
I tried to simulate this in LibreOffice:
Normal Removed As Space As 0
18/0113 180113 18 0113 1800113
18/0212 1802010 18 0212 18002010
180/2010 1802010 180 2010 18002010
180/2010 180212 180 2010 1800212
This thing could happen if '\' sign is not interpreted (as removed), or replaced by '0' in the background.
The main problem that we have many searches in programme where we suppose good evaluation, and we have more sites with different servers (and collation).
Hmmm...
Thanks
dd