On Sun, 13 Nov 2011 20:59:58 -0200, Adriano dos Santos Fernandes <adrian...@gmail.com> wrote: > On 13-11-2011 19:48, Alexandre Benson Smith wrote: >> >> I understand that such improvement could be hard to implement because of >> the changes on the API and that the access libraries must be recoded for >> such change, this could be a reason to post pone this modification, but
>> the argument that the other RDBMS don't support it so we should not >> support it either didn't convince me. >> > > In my opinion, DSQL XSQLVAR's should be make as it is now forever. It > was done bad, and change it would be bad too. I am not sure what you mean? XSQLVAR is bad, so we are not going to change it to something (potentially) better? > So, it's just a fact of allow it with the new API. And then there must > be a way to libraries uses bits of the new API mixed with old one. > > The increase of it is not difficult. I had it working for true 31-chars > UTF-8 names AFAIR. > > It's unlike that the new limit would be greater than 63 UTF-8 > characters, as 64 * 4 > 255 (blr limitation for names). UTF-8 is not 4 bytes, each character is encoded with a variable length of 1 to 4 bytes (technically the encoding supports 6 bytes, and some UCS-2 variants of UTF-8 use that instead of two surrogate pairs). Treating a UTF-8 encoded characters as 4 bytes per character is too naive and inefficient: for Western world most characters would occupy 1 byte. Treating it as actually being variable length instead of simply saying 'it's 4 bytes' would allow you to use 63 upto 254 characters, not just 63. BTW: Instead of saying 'it is a limit in BLR', what would be the effort to modify BLR to remove (or increase) this limitation? Mark ------------------------------------------------------------------------------ RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1 Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
