[EMAIL PROTECTED] wrote:
Jay Sprenkle <[EMAIL PROTECTED]> wrote:
On 11/1/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
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.
I think it's a bit misleading to call the library "SQL-Lite: if you're
going to redesign
and not be like SQL. What do you think about creating a separate
project for a fast
light database engine that's not "SQL Like"?
SQLite is very much SQL. It only deviates from the standard
to fix bugs in the original design of the standard.
--
D. Richard Hipp <[EMAIL PROTECTED]>
Richard,
This particular point is devolving into a semantic argument, so I
hesitate to continue down this road, but ... A language like SQL is
defined by its standard (warts and all).
If you develop something that conforms to some but not all of the
standard, especially if the non-conformities are by design, the best you
can say is that it is close to the standard.
Further, I would suggest that the arguments against your change are more
along the lines of "standards are good" rather than "strong typing is
good". Many people have learned the hard way that using multiple
implementations of something that are close to, but not quite standard,
often leads to problems. The C language had this problem before ANSI
standardization (and the release of conforming or nearly conforming
compilers by almost all vendors). The same source often produced
different results with different compilers. The use of language
extensions (i.e. fixes to design omissions) is also often fraught with
trouble.
If you set out to fix "bugs" in the design of a language, you are really
designing a new language. This is why we have C# , C++, and D (or even C
itself, which was a redesign of BCPL). They are all languages that were
developed to fix bugs that their creators saw in the C language or one
of its other derivatives.
The type of gratuitous non-conformance that you have proposed is almost
certainly going to lead to interoperability problems between SQLite and
other SQL implementations. It won't necessarily make SQLite itself
better or worse than the others, simply different. That difference will
then need to be allowed for by code that deals with different SQL
implementations.
This is your project (and I thank you very much for your work on it) so
it is ultimately your decision how SQLite will work. I just think that
you should very carefully consider any changes that will lead to less
conformance with the standard for the language that you are trying to
implement.
Dennis Cote
