On 11/4/21 6:56 PM, Karol Bieniaszewski wrote:
„The main reason why this "removal of trailing partial contraction" was done is to achieve behavior "consistent" with search/evaluation in other software (like text editors etc.), so (for example) STARTING WITH "C" or LIKE "C%" will return rows starting with "C" or "CH". This behavior itself is questionable (but more about that later) „ I try to understand the issue but meybe simpler description is required. When i use WIN1250 collate PXW_PLK (my Polish language) Then engine threat all „ch” as single letter in the index? And i cannot find looking by only „c” without „h” with index lookup? If yes how engine decide that this is „ch” or „c” and „h” in words? If i write: „chmura” it can be ok
May be the problem is difference of languages? See https://en.wikipedia.org/wiki/Ch_(digraph) :
In Czech alphabet, the digraph Ch is handled as a letter equal to other letters. In Czech dictionaries, indexes, and other alphabetical lists, it has its own section, following that of words (including names) beginning with /H/ and preceding that of words that begin with /I/. Thus, the word /chemie/ will not be found in the /C/ section of a Czech dictionary, nor the name /Chalupa/ in the /C/ section of the phonebook. The alphabetical order /h/ /ch/ is observed also when the combination /ch/ occurs in median or final position: /Praha/ precedes /Prachatice/, /hod/ precedes /hoch/.
But if i write (i write upper letter to show the problem): „cHandle” which is not „ch” at all?
As far as I understood reading wikis cHandle is not a problem - that's not Czech word, it's soone "C" locale. Same for Polish „chmura”. And must say that if we want to support Czech language correctly we must use key-based comparison for strings everywhere, and certainly for such digraph LIKE 'Czec%' should not match word 'Czech'.
What about current SQL standard - suppose there are just no Czech authors ;) Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
