Jay Sprenkle wrote:
Since SQL conformance is hard to legitimately define (Are we
going to conform to cj date, mysql, oracle, etc.) you're right,
it would be hard.
I believe my original suggestion still has value:
If DRH is going to radically change SQLite (removing/redefining typing
and redoing the expression evaluation) then a split/branch is valuable.
Jay,
I agree that moving away from the standard is a bad thing, but this
change does not in any way merit forking SQLite or changing its name.
SQLite currently deviates from the standard in much more significant
ways than this proposed (well its more than proposed now) change. It
lacks many standard functions, has no support for standard dates or
times, and no support for referential integrity for example.
SQLite currently covers a very large subset of standard SQL, and most of
the recent changes have been made in a way that makes it more standard
compliant. The recent changes to NULL handling in the SUM function and
the addition or correlated subqueries come to mind.
One of the things I see happening repeatedly around here is the
comparison of one SQL implementation to another. We are often asked how
does database X (or X, Y, and Z) do this. Also, people often justify
deviation from the standard because other databases also deviate from
the standard (perhaps even in different ways).
The solution to the compatibility problem is not to try match the
behavior of another database, but rather to match the behavior required
by the standard. If all the database implementations do this (and I
believe that most are generally trying to), then they will all
eventually become more and more compatible with each other as time goes
on. At some point the differences will be so small that they are seldom
an issue.
This will only be achieved if we continuously aim for standard
compliance. It is the target we should alway try to move towards, never
away from.
Many of the things we use everyday work only because all implementors
adhere to a common standard. Threading of nuts and bolts, USB devices,
compact disks, the C programming language, etc.as examples. These things
work well and interoperate because all implementors work from a common
standard. I'm sure each of these standards have some warts that could be
improved.
Generally fixing these problems isn't worth the loss of compatibility so
all implementations live with warts until a consensus arises that the
standard itself should be changed. At that point all implementation can
be revised at nearly the same time so the improvement is realized
without an attendant loss of compatibility.
Many good ideas have been sacrificed to maintain compatibility, but the
increased usability of compatible products is usually worth the
sacrifice. Truly great ideas often form the basis for a totally new way
of doing things which is completely incompatible with the previous
technology. Usually, these ideas will develop their own standard to
ensure compatibility between implementations.
I think this change is a good idea that should have been sacrificed for
compatibility. It's not such a great idea that it will spawn a whole new
industry centered around typeless databases engines. As a result of this
chnage SQLite has become a slightly less compatible database engine.
Well this post certainly drifted away from where I started.... but at
least that is off my chest.
In summary: SQLite is good. Standards are good. I hope SQLite moves
towards the SQL standard.
Dennis Cote
