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.
============================================================
