Re: case insensitive matching

>Date: Wed, 11 May 94 15:28:54 JST >From: Takeshi Houjyou <take-h@ascii.co.jp> >Subject: Re: case insensitive matching >X-Informix-List-Id: <list.3935> > >Sorry, I had to more explain. >>From: alan@po.den.mmc.com (Alan Popiel) >>Subject: Re: case insensitive matching >>X-Informix-List-Id: <list.3931> >> > .. stuff deleted .. >> >>I still would prefer a function like UPPER() for compatibility with other >>DBMS's, but if Informix would make the EMATCHES operator available in >>non-Japanese versions, it would go a long way toward addressing our needs. >> >Yes, EMATCHES can use for case insensitive matches in SQL statement, >4GL/ACE/PERFORM expression. Current Japanese version not handle in >4GL CONSTRUCT statement and PERFROM Query operation (always use MATCHES), >but modification is not so match difficult. > >But. Origin purpose of EMATCHES is code insensitive matches. Japanese >version Informix must handle ASCII and JIS(JIS X0208 and JIS X0201) code >in character field. JIS X0208 have symbole "A" and ASCII code have it. >EMATCHES operator match both. So EMATCHES is not only case insensitive >operator. > >I don't know Informix's strategy of internationalization, but I hope >if EMATCHES will be adopted, it work case and code insensitive operator. Everybody should be aware that there are at least two parts to handling case insensitive searching. First of all, the Engines (OnLine and SE) have to be made aware that they should do case-insensitive, codeset-insensitive or whatever searches. This means building into the Engine the EMATCHES operator, or the UPPER operator, or the LOWER operator, or a REGEXPR operator, or all of them. Once the Engines have been modified so that the SELECT statement can use these operators, then we can consider modifying the Tools (ISQL, I4GL) to make use of the extended notation. There are then all sorts of design issues -- such as how to indicate in a query-by-example whether this query is to be case sensitive or not (is it something the use can control by typing something in the field, or is it something controlled by the programmer), and so on. Until then, the limit of what can be implemented in I4GL is the UPSHIFT and DOWNSHIFT functions (which are already available). Of course, with I4GL, you can always write your own C code for use -- I have some regular expression code based on the regexpr(5) package, for example, which I can use on strings returned by the Engine. Practically nothing can be done in ISQL. We could, I suppose, provide some built-in functions for use in the INSTRUCTIONS section of a screen form or the FORMAT section of an ACE report. The trouble with these extensions is that the raw data has to be selected somehow, and sent back to the application so that the application can itself decide whether or not the data is what is wanted. While this is better than nothing, it is not really good enough. Once the Engines support the functionality, the Tools can be upgraded to make it generally available -- until then, we are all running with our hands tied behind our backs. Yours, Jonathan Leffler (johnl@informix.com) #include <disclaimer.h>