All of the arguments against my proposed changes are
basically of the form that "this is not what the SQL standard
says".  They are theoretical arguments based on a world-view
that holds that strong-typing is good and that it is the duty
of database systems to enforce types.

I do not hold to that world view.  SQLite seeks a better way.
You may or may not agree that the SQLite way is better (I
happen to think that it is, of course) but that is beside
the point.  What I want to know is whether or not my proposed
changes will cause serious hardship to any current or future
SQLite users.

Please let me restate the proposed change:  I desire to change
SQLite so that it no longer distinguishes between integer and
real.  The two concepts are merged into a unified "numeric" 
type.  Just as the same string can be represented as either
UTF-8 or UTF-16 (or sometimes ISO-8859) so too can a number
be represented as integer or real.  But regardless of the
particular representation chosen at any particular moment,
the "type" of the data is always "numeric".  There is no
"integer".  There is no "real".  There is only "numeric".
And because all number values are of the same type, they
need to always be treated in the same way.  A division should
return a result that includes the fractional part, if there 
is one, regardless of the particular representation of the
operands.

This a simplification designed to make your life easier.  No
longer are there different rules to apply depending on whether
a value or a column is "integer" or "real".  Everything always
works the same way.  The goal is to have no special cases.

I'm trying do all this while at the same time maintaining
reasonable compatibility with other SQL database engines.
SQLite will never be 100% compatible with other database
engines.  But on the other hand, I dare say you cannot find
any two other SQL database engines that are 100% compatible
with each other.  Most claim SQL compatibility, but you can
always find a corner case where two different engines will
give divergent results.  So even though SQLite is not 100%
compatible, neither is any other database engine.

With the above clarification, I will restate the question:
Suppose SQLite were to merge "integer" and "real" into a single
datatype "numeric" that always worked the same way.  Does
anybody know of a (real) usage example where this would cause
an actual hardship on developers?  Are there any examples of
things that you can do with separate "real" and "integer"
types that you cannot do with a unified "numeric" type?

--
D. Richard Hipp <[EMAIL PROTECTED]>

Reply via email to