On Mon, Jun 01, 2009 at 08:56:57PM -0700, Roger Binns wrote: > Dennis Cote wrote: > > Do you have a list of such changes that should be implemented in the > > next breaking release of SQLite? > > I assume you are talking about a major release (ie SQLite v4 not 3.7). > > > I'm thinking of things like renaming the _v2 API functions (in > > particular prepare_v2) to drop the suffix, > > That would change the ABI breaking any existing shared library linking. > It would be ok if there were separate SQLite v3 and v4 shared libraries.
I agree. The ABI must remain stable in 3.x, modulo some obsolescence policy (e.g., two minor releases between announcement of interface obsolescence and removal). Source compatibility (e.g., changing "char" to/from "unsigned char") is somewhat less important than ABI compatibility, but still a big deal. > My list of good changes to make are: +1 > Some nice to haves: > > - - Provide access to the SQL parse tree so that interactive tools can > provide a richer user experience. It is probably going too far from > *lite* but being able to change the tree would also allow external code > to perform query optimisation. This could be a separate library too, using shared source code. > - - Rejig the threading model so that each connection can only be used in > one thread. Provide some way to clone an existing open connection so > that the new cloned connection can be used in the other thread. Then > remove almost all of the mutexes etc since they are increasing hurtful > on modern machines (see memory write barriers as an example of why). +1 (Many libraries take that approach, and SQLite3 ought to as well, IMO.) Nico -- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
