<html> <head> <base href="https://bugs.documentfoundation.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - FIREBIRD: Couldn't create a varchar-field with less than 20 characters in GUI" href="https://bugs.documentfoundation.org/show_bug.cgi?id=105711#c9">Comment # 9</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - FIREBIRD: Couldn't create a varchar-field with less than 20 characters in GUI" href="https://bugs.documentfoundation.org/show_bug.cgi?id=105711">bug 105711</a> from <a class="email" href="mailto:lionel@mamane.lu" title="Lionel Elie Mamane <lionel@mamane.lu>"> Lionel Elie Mamane</a> <pre>(In reply to Tamas Bunth from <a href="show_bug.cgi?id=105711#c7">comment #7</a>) > The driver uses UTF-8 encoding for text-based columns (char, varchar, clob). > A character now occupies up to 4 bytes, so when the 'length' option in the > GUI is set to 5 it will allocate 20 bytes. > You can put more than 5 characters, because most of the characters don't > need all the 4 bytes. > SO what is the correct behavior of the 'length' GUI option set to 5? The expected behaviour is 5 characters ("codepoint" in Unicode terminology), independently of how many bytes that is. I understand Firebird deviates from the SQL standard in that respect, and takes a length in bytes. We could try to implement the "characters" thing within the Firebird SDBC driver (as your patch on gerrit tries to do, but I wouldn't bother. If we try to do that, there will always be cases that we won't catch. We will correctly implement that when the field is updated through the SDBC API, but then the user will do: SELECT LENGTH(field) as len FROM table; or UPDATE TABLE SET field='+' || field || '+'; and get unexpected results (results inconsistent with the GUI). I'd just let it be, and let the Firebird "misfeature" bubble up. A length of 5 in the GUI should be a VARCHAR(5) in Firebird. If firebird understands that as 5 bytes, then so be it. Maybe a middle ground would be to use UTF16 instead of UTF8 and let the length be UTF16 code units (that is length 5 is 10 bytes), if that's possible with Firebird. This is still a bug, but confusing character and UTF16 code units is so common that it usually not perceived as a bug. In my opinion, if this gives as a result that LENGTH(field) is in bytes and not in UTF16 code units, it is inconsistent and not desirable.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>