D. Richard Hipp wrote: > > Adding new result codes is complicated. There exist applications that > only check for the current set of result codes. So if new result > codes are added, those applications might fail. Hence adding new > result codes can lead to compatibility problems in legacy applications. >
Oh, that again. :-) It still seems to me that most applications embed the source of a particular version of sqlite, and those applications are safe until the developer updates them to a newer version. That developer is then responsible for ensuring his application code works correctly with the new version of sqlite he is updating to. He is also free to continue to use the older version of sqlite in his application if he doesn't want to make any sqlite related changes for a particular release. This sort of compatibility problem would only be an issue for updates to an sqlite shared library that multiple applications are linking to at run time. So this is perhaps another good reason not to do this. Perhaps the next major release should address this by specifically reserving the right to add new error codes in future versions, and requiring application developers (who are using a shared library) to be prepared to handle new, unknown, error codes. They can still call sqlite3_errmsg to get a string to report the new error, they just won't be able to assume that they can do anything in particular to recover from the new error. If they aren't prepared to do that, they can always eliminate the concern by statically linking to, or embedding, a particular version of sqlite, for which they can handle every possible error. > We have bigger fish to fry. > What kind of fish are you frying now, or is it top secret? Dennis Cote _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
