Yep. basically our "type less" string fields should have user definable operator overload functions. Sounds like a big change that I doubt DRH would implement anytime soon but it would definitely solve some of these integer/numeric/string/datetime/etc.. conversion/comparisons. We would also have to agree on what would constitute a constant custom data type declaration. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 13, 2004 11:41 AM To: Thomas, Basil Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: [sqlite] SQLite version 3 design question: '500'=500?
Not only comparison, but all expressions - arithmetic etc. [EMAIL PROTECTED] com To 13/05/2004 16:33 [EMAIL PROTECTED], [EMAIL PROTECTED] cc [EMAIL PROTECTED] Subject RE: [sqlite] SQLite version 3 design question: '500'=500? I think the point the SQL assumes is that everything is a string unless you tell it otherwise. How you tell it otherwise can be explicitly done or implicitly done. SQLite seems to be making implicit data conversions when in fact the user may mean something else. Therefore each implicit data conversion should also have an explicit data conversion to tell SQLite EXACTLY how to interpret this data type. Most relational systems have an enforced schema that dictates each allowable data type and how these data types can be converted from one type to another. SQLite which is basically type less, should allow us to add functions to overload the comparison operators so that we could convert/compare explicitly for each of our custom data types since we know exactly what we want . This should be optional and would probably impact performance but at least we would get the right answer whenever we queried for the custom data types that we have defined. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Thursday, May 13, 2004 11:18 AM To: Fred Williams Cc: [EMAIL PROTECTED] Subject: RE: [sqlite] SQLite version 3 design question: '500'=500? Not terribly interested in pursuing this, but that is precisely the point - letting the engine handle the 'technical' things means it needs to know the types of data in it. If the engine doesn't do it, the user has to do it, adding complexity and producing less reliable systems. "Fred Williams" <[EMAIL PROTECTED] on.net> To <[EMAIL PROTECTED]> 13/05/2004 15:12 cc <[EMAIL PROTECTED]> Subject RE: [sqlite] SQLite version 3 design question: '500'=500? I guess you read different books than I. The intent was to have the language engine do the required type conversions freeing the user from knowledge of such "technical" things. Like all languages it evolved, and has not remained "simple." Fred > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 13, 2004 8:51 AM > To: Fred Williams > Cc: [EMAIL PROTECTED] > Subject: RE: [sqlite] SQLite version 3 design question: '500'=500? > > > > > > > > Funny, I thought SQL was a more down to earth version of E. F. Codd's > mathematical model 'Relational Algebra', with some concepts taken from > Relational Calculus. > > To say types and strong typing weren't part of the original SQL concept > isn't right. Typing gives data semantics. > > Vijay > ... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ------------------------------------------------------------This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. ============================================================ ------------------------------------------------------------This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately. Ce courrier électronique est confidentiel et protégé. L'expéditeur ne renonce pas aux droits et obligations qui s'y rapportent. Toute diffusion, utilisation ou copie de ce message ou des renseignements qu'il contient par une personne autre que le (les) destinataire(s) désigné(s) est interdite. Si vous recevez ce courrier électronique par erreur, veuillez m'en aviser immédiatement, par retour de courrier électronique ou par un autre moyen. ============================================================