-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Lukas Gebauer wrote: > I am not creating and releasing savepoints!
Yes you are. The SQLite library is not magically doing them on a whim. Your code is asking for them. >> You can create a custom wrapper for savepoints which may have >> the stack of calls. > > Why I must duplicate code what is inside Sqlite too? There is no code inside SQLite that returns the list of savepoints so there is nothing to duplicate. There is a data structure of savepoints. Adding this code and API seems simple enough and superficially it is. However once added it cannot be removed (dynamic linking would break), has to be documented and tested, and adds some bloat to SQLite. It would also constrain future changes to underlying data structures. For example if the public API returns a flat list, it would complicate things if the internal data structure would be better off as a tree. Although it may not seem like it, one of the most important jobs of project maintainers is saying "no". Here is Linus Torvalds on the subject: http://linuxmafia.com/faq/Kernel/linus-im-a-bastard-speech.html > Sqlite have savepoint stack inside (AFAIK). I really not know why is > a problem to list this stack through some API. (But maybe it really > is a problem, I don't know, but nobody tell this yet...) This code will print out the names to stderr. You should be able to do the equivalent from your debugger. void print_savepoints(sqlite3 *db) { int i; for(i=0;i<db->nSavepoint;i++) fprintf(stderr, "%s\n", db->pSavepoint[i]->zName); } They are also in a tree like structure so it isn't quite that simple. > Yes, I can create my own wrapper, what can work with my code only, It is your code that needs debugging :-) > Just because I must duplicate > lot of code for decide if savepoint is or not is created, If you have random code generating random SQL then it is harder, but that is a bad design anyway. Generally you'll have a function that when called generates savepoints and another for rolling them back. But even with random code, the authorizer interface can tell you when savepoint SQL is prepared. > And now compare it with simple API funtion what just list existing > savepoint stack inside Sqlite. It is simple, trivial, useful... and > working right at any case. And constrains data structures, requires documentation and testing, can never be removed and adds bloat. And in most cases still isn't useful by itself - you would still need to add yet another wrapper around that function depending on what you want to happen (print it indented as a tree, convert to utf16 or ascii, combine names separated by commas, stdout or stderr, gui dialog etc). > This is why I am asking for. Thanks! A simple rule of thumb is to look at how useful features would be to other SQLite users. Note that you are the only one to have asked for this feature and not one other person has agreed with you on its need! The responses have generally been along the lines of suggesting you organize your code so that you do not need it. But even if it was added as a debugging aid, do you expect people to compile up two versions of SQLite - one with debugging aids on and another with them off? This feature would impose decisions like that on others in addition to the future maintenance costs. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkq3uvIACgkQmOOfHg372QQI/QCcDDg5dthEmqBJj+FZL5NhatN2 JusAoMSHlyXRJsLHMhCF+S3vQgKFUX7E =+RxM -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
