*** 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.
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|