Re: [sqlite] Types for strings, non-expert question
Roger Binns wrote: > I assume you are talking about a major release (ie SQLite v4 not 3.7). > Yes, that's what I'm talking about. I would expect v3 and v4 to be maintained in parallel until most users have updated their code to work with v4. Of course users could continue to use v3 indefinitely, but as some point it would go into feature freeze and all new development would take place in the v4 branch. That wouldn't mean that v3 suddenly stops working. This is basically what happen with the transition from v2 to v3. In fact there are still some users happily using v2. I suspect the transition would actually be quite quick, though existing versions of v3 would continue to be used for many years. > > My list of good changes to make are:... > Those are exactly the kinds of changes that I think should be collected and published so they can be vetted by users and the developers before the changes are implemented. I think it could help to avoid future errors like the sqlite_column_text return type issue. Dennis Cote ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Types for strings, non-expert question
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
Re: [sqlite] Types for strings, non-expert question
-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
Re: [sqlite] Types for strings, non-expert question
D. Richard Hipp wrote: > On May 27, 2009, at 9:36 AM, Maurí cio wrote: > > >> Hi, >> >> I see that in most functions strings are typed as >> >> char * >> >> while in 'sqlite_column_text' and 'sqlite_value_text' >> they are typed as >> >> unsigned char * >> >> > > That was just bad design on my part. I don't know what I was thinking > when I did that. It has been a pain for everyone to deal with ever > since. But we cannot change it now without breaking compatibility. > > On the other hand, as long as you use the characters as characters and > not as integers, does it really matter if they are signed or > unsigned? Just cast the result to whatever you need and it will work. > > > Richard, Do you have a list of such changes that should be implemented in the next breaking release of SQLite? I'm thinking of things like renaming the _v2 API functions (in particular prepare_v2) to drop the suffix, and changing the name of the CURRENT_TIMESTAMP default value to CURRENT_DATETIME so that CURRENT_TIMESTAMP can be used for an julian day number, etc. Dennis Cote ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Types for strings, non-expert question
On May 27, 2009, at 9:36 AM, Maurí cio wrote: > Hi, > > I see that in most functions strings are typed as > > char * > > while in 'sqlite_column_text' and 'sqlite_value_text' > they are typed as > > unsigned char * > That was just bad design on my part. I don't know what I was thinking when I did that. It has been a pain for everyone to deal with ever since. But we cannot change it now without breaking compatibility. On the other hand, as long as you use the characters as characters and not as integers, does it really matter if they are signed or unsigned? Just cast the result to whatever you need and it will work. D. Richard Hipp d...@hwaci.com ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Types for strings, non-expert question
Hi, I see that in most functions strings are typed as char * while in 'sqlite_column_text' and 'sqlite_value_text' they are typed as unsigned char * Is there something I should have in mind about that when writing a binding to sqlite3 from another language? Can I type both as beeing the same? Thanks, Maurício ___ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
