04.05.2015 14:07, Alex Peshkoff wrote: > This is just technical issue, and btw we do not need it now - required > functionality is present using 15 lines code and not too big table.
Only if you are determined to ignore SQL standard. Besides, I doubt that "15 lines of code and not too big table" will allow you to convert any character set to upper-cased UTF-8 (see my last comment in the ticker). By the standard there are following cases: 1. An identifier contain letters [A-Z0-9_$]. 2. An identifier contain letters [a-z0-9_$]. 3. An identifier is starting from a digit. 4. The rest. Case 1 is to be case-insensitive. Cases 3 and 4 are to be case-sensitive. Case 2 is in doubts. All non-ascii identifiers fall to case 4, so, by standard they have to be case-sensitive. > This routine is not good for logins. Try to pass sysdba to it. You are right. This routine is not good for logins. But similar routine that threat case 2 the same way as case 1 - could be. You suggested to break SQL standard completely and make cases 3 and 4 case-insensitive. I suggest to break standard partially and make case 2 always case-insensitive while keep cases 3 and 4 case-sensitive. This way we keep backward compatibility and follow SQL standard as much as possible. -- WBR, SD. ------------------------------------------------------------------------------ One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
