*** 26,36 **** of precompiling is greatly reduced. ----- ! ! 22-July-2003: There is now an *experimental* API in SQLite CVS (checkin [1060]) that can be used for pre-compiled queries: sqlite_reset( sqlite_vm *, const char **, sqlite_vm ** ppVm); --- 26,37 ---- of precompiling is greatly reduced. ----- ! 2003-07-22: There is now an *experimental* API in SQLite CVS (checkin [1060]) that can be used for pre-compiled queries: + _(This API has changed as of 2003-09-06. See below for additional + information.)_ sqlite_reset( sqlite_vm *, const char **, sqlite_vm ** ppVm); *************** *** 55,62 **** make here. ----- ! ! 24-July-2003: Some performance results for pre-compiled queries. The temp db was using the in-memory backend. --- 56,62 ---- make here. ----- ! 2003-07-24: Some performance results for pre-compiled queries. The temp db was using the in-memory backend. *************** *** 97,99 **** --- 97,147 ---- If you use an INTEGER PRIMARY KEY instead of a PRIMARY KEY things are slightly faster all round. The relative benefit of pre-compiled queries is slightly increased (5-10%) as well. The program to run this test is {link: http://cvs.hwaci.com/sqlite/attach_get?id=58,precomp_test.c precomp_test.c}. It builds against 2.8.5. + + ---- + 2003-09-06: + + The experimental sqlite_reset() API has changed to be the following: + + int sqlite_reset(sqlite_vm *pVM, char **pzErrMsg); + + Use this routine like sqlite_finalize() after you finish with a run of + the virtual machine. It returns an error code and writes any error + message into pzErrMsg. But instead of deleting the virtual machine, + it resets it so that it is ready to run again. The same VM can be run + over and over. + + The SQL that you pass to sqlite_compile() can now contain "variables" + represented by question marks. For example: + + INSERT INTO tab1 VALUES(?,?,?) + + After calling sqlite_compile() or sqlite_reset(), you can fill in the + values for the question marks using the new sqlite_bind() API: + + sqlite_bind(sqlite_vm *pVm, int idx, const char *zVal, int len, int copy); + + The first parameter is the virtual machine you want to bind values to. + The second parameter "idx" specifies which variable (or "?") is to + receive the value. + The variables are number from left to right beginning with 1. So in the + example above, the variables are 1, 2, and 3. The third parameter is the + value to assign to the variable. The fourth parameter is the length of + the data in zVal, including the \000 terminator. You can use -1 here and + sqlite_bind() will figure out the length for itself using strlen(). + The fifth and last parameter is a flag that is TRUE if you want SQLite to + make a copy of the value for itself in memory obtained from malloc(). If + the fifth parameter is false, SQLite assumes that zVal is unchanging and + that the virtual machine can just whatever memory zVal points to without + having to make its own copy. + + You can bind the same variable multiple times. If zVal==0, that is the + same as setting the variable to NULL. Unbound variables are interpreted + as NULL. + + The "len" parameter (the 4th parameter) is intended to let you insert + binary data into the database. zVal does not really have to be \000 + terminated - it can be any sequence of bytes you want. "len" is just the + number of bytes in that sequence. Such is the intent of "len" - but it + has not test and any attempts to use it like that at this point will likely + encounter bugs. You have been warned.