Rodger: Thanks for creating the ticket. I will be interested to see the result when (if? :-) it gets implemented.
Dan: It was my thought that a single, well thought-out implementation of caching (as opposed to something that each programmer implements on an 'ad-hoc' basis) would offer a speed advantage to all, and would even be source-code compatible for existing programs. As for internal vs. external, Do you mean 'external' as an add-on library that 'wraps' the prepare* statements? It could be done, but I'm not (personally) fond of the idea. Either some fancy linking is needed to replace the affected calls with 'new' versions (doesn't sound like fun when you want to do it across a wide range of platforms), or a new function call name (which is not source-compatible) would be necessarily. If by 'external' you meant 'in the API' as opposed to 'in the engine itself', I don't feel I have enough background in sqlite internals to express an opinion. *** Doug Fajardo -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dan Sent: Friday, November 07, 2008 9:20 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Distinguishing between sqlite3_stmts On Nov 8, 2008, at 3:25 AM, Roger Binns wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Douglas E. Fajardo wrote: >> ( To the 'powers that be'... I wonder if some form of 'cache' for >> prepared statements might be built in to the 'sqlite3_prepare*' >> functions as a performance enhancement? ) > > I couldn't find an existing ticket so created a new one: > > http://www.sqlite.org/cvstrac/tktview?tn=3483 Are there advantages to implementing this internally instead of externally? _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
