On 04/05/2016 05:13 PM, Dimitry Sibiryakov wrote: > 05.04.2016 15:53, Alex Peshkoff wrote: >> But there are a lot of other places where NoCaseString is used. And it's >> very efficient when case-insensitive strings are needed. It will be not >> good to loose such class. > Yes. But in most of these places using of case-insensitive string is > causing bugs. For > example, using it in map hash not only fail now, but also is causing > dangerous situation > when on POSIX users from Security4.fdb can be used instead of the same users > from > security4.fdb and vice versa. User SySdBa also can be mixed up by engine with > user SYSDBA. > You know consequences.
According to SQL standard SySdBa and SYSDBA is same user, "SySdBa" and "SYSDBA" differ. And you are right - another class, following SQL standard is needed here. Looks like it will be free of non-ascii comparison issues cause non-ascii symbols can be entered only double-quoted and therefore are case sensitive. > >> What prevents from (for example) making them always utf-16 and >> performing case-insensitive comparison for them? > Too many things will be broken. Second-fresh developers are not allowed > to cause > regressions. > That's a problem :) Getting serious - I do not expect commit changing INTL rules inside engine to break nothing because it's too big. The only requirement is to support that changes when bugs are found. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
