-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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. My list of good changes to make are: - - Make the types be #defines/typedefs overrideable at compile time. That way the developer can tune to meet their needs especially on less mainstream platforms. - - Use standard C types like size_t rather than int so that the code is 64 bit clean. Other than my own code :), all the open source projects I examined behaved as though the SQLite API did in fact take size_t which could result in truncation on 64 bit platforms. Some of the compiler warnings are due to this sort of thing. #3246. A separate issue is if SQLite should support objects larger than 2GB on 64 bit platforms. #2125. - - Use enums liberally such as for the result codes. The purpose behind this is to give the compiler more information so that it can generate better warnings (for example gcc will warn about switch statements omitting values). The ultimate goal would be to make the API hard to misuse. Rusty Russell has posted various things about that. You can also use gcc macros to cause warnings, such as how the kernel defines min if the types don't match. Other function annotations are also available although SQLite experience hasn't been too good - see the attempts to mark functions as experimental or deprecated. #3365 - - Fix threading error reporting. Currently the err message and code are global to the connection. If the same connection is used in multiple threads then the values can be clobbered by other threads. The fix would be to make the error string/code thread local just like errno and GetLastError behave. #3142, #3498 - - Implement reference counting and xDelete callbacks in all the apis. For example there is currently no way to tell if a function is no longer used, if a vfs is in use, but you can for collations. These are less of an issue in the C api but a big hassle when bound to a dynamic language. #3141 - - Make it possible to localise error messages. Provide more detail in some (eg constraints failed) so that they could be presented to users. #3456, #1648 Some nice to haves: - - Provide all functionality as (possibly optional) parts of the amalgamation. For example the genfkey code is only available to the shell. I can't provide it via my Python wrapper. #3687 - - 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. - - 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). And some things SQLite does well: The usual: it works, thoroughly tested, frequent releases, responsive to feedback, steady stream of performance and new features while remaining backwards compatible, vibrant community from little guys through to the members of the consortium. I also hope that DRH and the other authors make a good living from the project. I love the amalgamation. It is so trivial to include, switch versions etc. The compilers even have fun inlining stuff and other optimisations. The documentation is very good. I often feel embarrassed that the only issues I report seem rather petty! Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkokowUACgkQmOOfHg372QQUXACgsD/PcII9sRSajy120KQjOmvE kmcAn24ACFTy9Unq66UXnF6/L1uPLaVj =Zdwm -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
