mirrors/sqlite
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Documentation updates in preparation for the release of version 3.0.0. (CVS 1613)

Browse Source 
FossilOrigin-Name: 9fb29f7331254b601b71f0fe7d77f91915272dc7
This commit is contained in:
drh 2004-06-17 19:04:17 +00:00
parent ededfd5e83
commit a285422922
13 changed files with 592 additions and 236 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
main.mk
View File

@ -458,6 +458,9 @@ tclsqlite.html: $(TOP)/www/tclsqlite.tcl
vdbe.html: $(TOP)/www/vdbe.tcl
tclsh $(TOP)/www/vdbe.tcl >vdbe.html
version3.html: $(TOP)/www/version3.tcl
tclsh $(TOP)/www/version3.tcl >version3.html
# Files to be published on the website.
#
@ -493,7 +496,8 @@ DOC = \
sqlite.html \
support.html \
tclsqlite.html \
vdbe.html
vdbe.html \
version3.html
doc: common.tcl $(DOC)
mkdir -p doc

33
manifest
View File

@ -1,5 +1,5 @@
C Remove\sredundant\sopcodes\sOP_MakeKey\sand\sOP_MakeIdxKey.\s(CVS\s1612)
D 2004-06-17T07:53:02
C Documentation\supdates\sin\spreparation\sfor\sthe\srelease\sof\sversion\s3.0.0.\s(CVS\s1613)
D 2004-06-17T19:04:17
F Makefile.in ab7b0d5118e2da97bac66be8684a1034e3500f5a
F Makefile.linux-gcc a9e5a0d309fa7c38e7c14d3ecf7690879d3a5457
F README f1de682fbbd94899d50aca13d387d1b3fd3be2dd
@ -17,7 +17,7 @@ F doc/lemon.html f0f682f50210928c07e562621c3b7e8ab912a538
F doc/report1.txt a031aaf37b185e4fa540223cb516d3bccec7eeac
F install-sh 9d4de14ab9fb0facae2f48780b874848cbf2f895
F ltmain.sh f6b283068efa69f06eb8aa1fe4bddfdbdeb35826
F main.mk 26a2e950660b952a98fd2772d4375636a5c9651b
F main.mk 6004a81e05581a6b51e4f37a62ed45db089c47cf
F mkdll.sh 68d34a961a1fdfa15ef27fc4f4740be583112124
F publish.sh e772c09c4fb72f2323a1fb522259640e52040b15
F spec.template a38492f1c1dd349fc24cb0565e08afc53045304b
@ -44,19 +44,19 @@ F src/os.h 1cb5f0293a30288451fe3c0c73815cf208212ed1
F src/os_common.h ba1b7306e16e2091718f2c48db0fe6c1d7a31bb8
F src/os_mac.c 3d31e26be1411acfb7961033098631b4f3486fdf
F src/os_mac.h 51d2445f47e182ed32d3bd6937f81070c6fd9bd4
F src/os_unix.c 8832c78dd95c115b1690054354d90321a791950d
F src/os_unix.c 132864ff574571929f51b1b19b47e988a4468404
F src/os_unix.h 1cd6133cf66dea704b8646b70b2dfdcbdd9b3738
F src/os_win.c 337e973ee77797aaab4787e3477a5945fcd97266
F src/os_win.h 004eec47b1780fcaf07420ddc2072294b698d48c
F src/pager.c 453099416c10669365ca70f12f13e67e6ef11000
F src/pager.h bc58d32a9dee464f7268fb68652c130a4216e438
F src/parse.y 097438674976355a10cf177bd97326c548820b86
F src/pragma.c b51bd2034a54f62a72ad454028712afaa294ff94
F src/pragma.c 83b86b2942d7f1b202644ac4e2559965e23a8a7b
F src/printf.c 7e7f83a747bbd0601dcb4ee2885fb3ce3e994a9f
F src/random.c eff68e3f257e05e81eae6c4d50a51eb88beb4ff3
F src/select.c 91570af7f13d1c5584f3b711676e1226ee12194e
F src/shell.c ca519519dcbbc582f6d88f7d0e7583b857fd3469
F src/sqlite.h.in 36c253844656186ca53e1999efa6ef7b44f88779
F src/sqlite.h.in eacd23af3280603cd8b48979c6f9297b3ac2935c
F src/sqliteInt.h 59c1e1b637e7cf329f39425469bc4dbeab1fa1d5
F src/table.c af14284fa36c8d41f6829e3f2819dce07d3e2de2
F src/tclsqlite.c 6f88be282a3617c6739c043fd13571b5f2fe9922
@ -193,24 +193,24 @@ F www/arch2.fig 613b5ac63511109064c2f93c5754ee662219937d
F www/arch2.gif 49c6bb36160f03ca2b89eaa5bfb1f560c7d68ee7
F www/audit.tcl 90e09d580f79c7efec0c7d6f447b7ec5c2dce5c0
F www/c_interface.tcl 2176519fc2bd2d2cf6fe74fd806fc2d8362de2c8
F www/capi3.tcl a940c5ca0b0ebafd5acfe2ceca5a388bd8cfb468
F www/capi3ref.tcl 7a6e81eebe20b960aed02cb33e369b3645acceec
F www/capi3.tcl 9e6a4b21f464d84b385dd5e78292880fc74a47ab
F www/capi3ref.tcl 68a03fa5c15f01d04fbb073f8153078f1ba6f672
F www/changes.tcl cbe942607b2b9e5dc995395f37042dbb5a629c7f
F www/common.tcl f786e6be86fb2627ceb30e770e9efa83b9c67a3a
F www/conflict.tcl fb8a2ba83746c7fdfd9e52fa7f6aaf5c422b8246
F www/copyright-release.html 294e011760c439c44951a6bfecd4c81a1ae359e8
F www/copyright-release.pdf cfca3558fc97095e57c6117d08f1f5b80d95125a
F www/copyright.tcl 82c9670c7ddb0311912ab7fe24703f33c531066c
F www/datatype3.tcl f48b05cafd5e54ae5c05e643169d5217ee51a244
F www/datatype3.tcl dadcd0b09dc6fdf86d0c38499e310ae94cb586d7
F www/datatypes.tcl 566004b81c36877397ddbe6e1907aae6065f6b41
F www/docs.tcl a924a5043973a70c58b65abf1051ed8b1238864d
F www/docs.tcl 095b5718ec044156af477061566ea25632624b56
F www/download.tcl 075e21eb50ec6a3f29cdf2a011770a02187592eb
F www/dynload.tcl 02eb8273aa78cfa9070dd4501dca937fb22b466c
F www/faq.tcl 3a1776818d9bd973ab0c3048ec7ad6b1ad091ae5
F www/fileformat.tcl f71a06a0d533c7df408539c64113b4adeaf29764
F www/formatchng.tcl d1dfecedfb25e122ab513a1e0948b15cb4f0be46
F www/index.tcl a3d658c44b27ca28b0b660e2a3903ee39f052dea
F www/lang.tcl fc528581c4a406cabc138e2f17db5ef6f38615ff
F www/index.tcl 9783a8370bf16dfc20e81f1cf14489f95408353e
F www/lang.tcl 608a3504fe59699699ca6faf3f7142e067a9f383
F www/lockingv3.tcl afcd22f0f063989cff2f4d57bbc38d719b4c6e75
F www/mingw.tcl d96b451568c5d28545fefe0c80bee3431c73f69c
F www/nulls.tcl f31330db8c978e675f5cd263067b32b822effa6f
@ -223,8 +223,9 @@ F www/sqlite.tcl b51fd15f0531a54874de785a9efba323eecd5975
F www/support.tcl 1801397edd271cc39a2aadd54e701184b5181248
F www/tclsqlite.tcl 19191cf2a1010eaeff74c51d83fd5f5a4d899075
F www/vdbe.tcl 59288db1ac5c0616296b26dce071c36cb611dfe9
F www/version3.tcl f9a4c1a12864e129f6717d22313be01d5657e3aa
F www/whentouse.tcl a8335bce47cc2fddb07f19052cb0cb4d9129a8e4
P 12e77e759ec5b45b7fb94aa815435127f395162e
R aebc8fd8caefcbe7b2df44794110fc94
U danielk1977
Z f3b130fff0bc0063d640a9d3c08bfe60
P a71a9ff114f2162696d8d37fbc87b315568f6dcb
R 0c1c395d17282923e97a25ac9186d69a
U drh
Z 95db50b2b10478702338303008862d5b

2
manifest.uuid
View File

@ -1 +1 @@
a71a9ff114f2162696d8d37fbc87b315568f6dcb
9fb29f7331254b601b71f0fe7d77f91915272dc7

21
src/os_unix.c
View File

@ -607,17 +607,22 @@ int sqlite3OsSeek(OsFile *id, off_t offset){
int sqlite3OsSync(OsFile *id){
SimulateIOError(SQLITE_IOERR);
TRACE2("SYNC %-3d\n", id->h);
{
off_t sz;
sqlite3OsFileSize(id, &sz);
fprintf(stderr,"SYNC %d size=%lld... ", id->h, sz);
}
if( fsync(id->h) ){
return SQLITE_IOERR;
}else{
if( id->dirfd>=0 ){
TRACE2("DIRSYNC %-3d\n", id->dirfd);
fsync(id->dirfd);
close(id->dirfd); /* Only need to sync once, so close the directory */
id->dirfd = -1; /* when we are done. */
}
return SQLITE_OK;
}
if( id->dirfd>=0 ){
TRACE2("DIRSYNC %-3d\n", id->dirfd);
fsync(id->dirfd);
close(id->dirfd); /* Only need to sync once, so close the directory */
id->dirfd = -1; /* when we are done. */
}
fprintf(stderr,"DONE\n");
return SQLITE_OK;
}
/*

4
src/pragma.c
View File

@ -11,7 +11,7 @@
*************************************************************************
** This file contains code used to implement the PRAGMA command.
**
** $Id: pragma.c,v 1.45 2004/06/16 12:02:43 danielk1977 Exp $
** $Id: pragma.c,v 1.46 2004/06/17 19:04:17 drh Exp $
*/
#include "sqliteInt.h"
#include <ctype.h>
@ -124,10 +124,12 @@ static int flagPragma(Parse *pParse, const char *zLeft, const char *zRight){
{ "vdbe_trace", SQLITE_VdbeTrace },
{ "sql_trace", SQLITE_SqlTrace },
{ "vdbe_listing", SQLITE_VdbeListing },
#if 1 /* FIX ME: Remove the following pragmas */
{ "full_column_names", SQLITE_FullColNames },
{ "short_column_names", SQLITE_ShortColNames },
{ "count_changes", SQLITE_CountRows },
{ "empty_result_callbacks", SQLITE_NullCallback },
#endif
};
int i;
for(i=0; i<sizeof(aPragma)/sizeof(aPragma[0]); i++){

12
src/sqlite.h.in
View File

@ -12,7 +12,7 @@
** This header file defines the interface that the SQLite library
** presents to client programs.
**
** @(#) $Id: sqlite.h.in,v 1.101 2004/06/12 09:25:20 danielk1977 Exp $
** @(#) $Id: sqlite.h.in,v 1.102 2004/06/17 19:04:17 drh Exp $
*/
#ifndef _SQLITE_H_
#define _SQLITE_H_
@ -950,6 +950,16 @@ void *sqlite3_user_data(sqlite3_context*);
void *sqlite3_get_auxdata(sqlite3_context*, int);
void sqlite3_set_auxdata(sqlite3_context*, int, void*, void (*)(void*));
/*
** These are special value for the destructor that is passed in as the
** final argument to routines like sqlite3_result_blob(). If the destructor
** argument is SQLITE_STATIC, it means that the content pointer is constant
** and will never change. It does not need to be destroyed. The
** SQLITE_TRANSIENT value means that the content will likely change in
** the near future and that SQLite should make its own private copy of
** the content before returning.
*/
#define SQLITE_STATIC ((void(*)(void *))0)
#define SQLITE_TRANSIENT ((void(*)(void *))-1)

161
www/capi3.tcl
View File

@ -1,4 +1,4 @@
set rcsid {$Id: capi3.tcl,v 1.3 2004/06/01 10:01:25 drh Exp $}
set rcsid {$Id: capi3.tcl,v 1.4 2004/06/17 19:04:17 drh Exp $}
source common.tcl
header {C/C++ Interface For SQLite Version 3}
puts {
@ -27,6 +27,7 @@ requires incompatible changes to the database file format. Other
incompatible changes, such as a cleanup of the API, were introduced
at the same time under the theory that it is best to get your
incompatible changes out of the way all at once.
</p>
<p>
The API for version 3.0 is similar to the version 2.X API,
@ -48,12 +49,37 @@ to whatever datatype is appropriate for their system.
<h3>2.0 C/C++ Interface</h3>
<p>
The API for SQLite 3.0 three includes 83 separate functions in addition
to several data structures and #defines. (A complete
<a href="capi3ref.html">API reference</a> is provided as a separate document.)
Fortunately, the interface is not nearly as complex as its size implies.
Simple programs can still make due with only 3 functions:
<a href="capi3ref.html#sqlite3_open">sqlite3_open()</a>,
<a href="capi3ref.html#sqlite3_exec">sqlite3_exec()</a>, and
<a href="capi3ref.html#sqlite3_close">sqlite3_close()</a>.
More control over the execution of the database engine is provided
using
<a href="capi3ref.html#sqlite3_prepare">sqlite3_prepare()</a>
to compile an SQLite statement into byte code and
<a href="capi3ref.html#sqlite3_prepare">sqlite3_step()</a>
to execute that bytecode.
A family of routines with names beginning with
<a href="capi3ref.html#sqlite3_column_blob">sqlite3_column_</a>
is used to extract informatiom about the result set of a query.
Many interface functions come in pairs, with both a UTF-8 and
and UTF-16 version. And there is a collection of routines
used to implement user-defined SQL functions and user-defined
text collating sequences.
</p>
<h4>2.1 Opening and closing a database</h4>
<blockquote><pre>
typedef struct sqlite3 sqlite3;
int sqlite3_open(const char*, sqlite3**, const char**);
int sqlite3_open16(const void*, sqlite3**, const char**);
int sqlite3_open(const char*, sqlite3**);
int sqlite3_open16(const void*, sqlite3**);
int sqlite3_close(sqlite3*);
const char *sqlite3_errmsg(sqlite3*);
const void *sqlite3_errmsg16(sqlite3*);
@ -62,7 +88,8 @@ to whatever datatype is appropriate for their system.
<p>
The sqlite3_open() routine returns an integer error code rather than
a pointer to the sqlite3 structure. The difference between sqlite3_open()
a pointer to the sqlite3 structure as the version 2 interface did.
The difference between sqlite3_open()
and sqlite3_open16() is that sqlite3_open16() takes UTF-16 (in host native
byte order) for the name of the database file. If a new database file
needs to be created, then sqlite3_open16() will set the internal text
@ -71,12 +98,10 @@ representation to UTF-8.
</p>
<p>
The third "const char**" argument to sqlite3_open() is a NULL-terminated
list of keyword/value pairs that define options to apply to the open
request. The third argument may be NULL if there are no options.
This extra argument provides an expandable way of supporting new features
in future releases. For example, a future release may contain an
option to define an encryption/decryption key.
The opening and/or creating of the database file is deferred until the
file is actually needed. This allows options and parameters, such
as the native text representation and default page size, to be
set using PRAGMA statements.
</p>
<p>
@ -125,25 +150,57 @@ They are as follows:
<h4>2.2 Executing SQL statements</h4>
<blockquote><pre>
typedef int (*sqlite_callback)(void*,int,char**, char**);
int sqlite3_exec(sqlite3*, const char *sql, sqlite_callback, void*, char**);
</pre></blockquote>
<p>
The sqlite3_exec function works much as it did in SQLite version 2.
Zero or more SQL statements specified in the second parameter are compiled
and executed. Query results are returned to a callback routine.
See the <a href="capi3ref.html#sqlite3_exec">API reference</a> for additional
information.
</p>
<p>
In SQLite version 3, the sqlite3_exec routine is just a wrapper around
calls to the prepared statement interface.
</p>
<blockquote><pre>
typedef struct sqlite3_stmt sqlite3_stmt;
int sqlite3_prepare(sqlite3*, const char*, sqlite3_stmt**, const char**);
int sqlite3_prepare16(sqlite3*, const void*, sqlite3_stmt**, const void**);
int sqlite3_prepare(sqlite3*, const char*, int, sqlite3_stmt**, const char**);
int sqlite3_prepare16(sqlite3*, const void*, int, sqlite3_stmt**, const void**);
int sqlite3_finalize(sqlite3_stmt*);
int sqlite3_reset(sqlite3_stmt*);
</pre></blockquote>
<p>
The non-callback API is now the preferred way of accessing the database.
Wrapper functions that emulate the older callback API may (or may not)
be provided.
The sqlite3_prepare interface compiles a single SQL statement into byte code
for later execution.
This interface is now the preferred way of accessing the database.
</p>
<p>
The sqlite3_prepare() function compiles an single SQL statement.
The statement may contain tokens of the form "?" or "?nnn" or ":nnn:"
The SQL statement is a UTF-8 string for sqlite3_prepare().
The sqlite3_prepare16() works the same way except
that it expects a UTF-16 string as SQL input.
Only the first SQL statement in the input string is compiled.
The fourth parameter is filled in with a pointer to the next (uncompiled)
SQLite statement in the input string, if any.
The sqlite3_finalize() routine deallocates a prepared SQL statement.
All prepared statements must be finalized before the database can be
closed.
The sqlite3_reset() routine resets a prepared SQL statement so that it
can be executed again.
</p>
<p>
The SQL statement may contain tokens of the form "?" or "?nnn" or ":nnn:"
where "nnn" is an integer. Such tokens represent unspecified literal values
(or wildcard) to be filled in later by the sqlite3_bind() API.
(or wildcards) to be filled in later by the
<a href="capi3ref.html#sqlite3_bind_blob">sqlite3_bind</a> interface.
Each wildcard as an associated number given
by the "nnn" that follows the "?". If the "?" is not followed by an
integer, then its number one more than the number of prior wildcards
@ -153,26 +210,14 @@ all instance of that wildcard will be filled in with the same value.
Unbound wildcards have a value of NULL.
</p>
<p>The SQL statement is a UTF-8 string for sqlite3_prepare().
The sqlite3_prepare16() works the same way except
that it expects a UTF-16 string as SQL input.
Only the first SQL statement in the input string is compiled.
The fourth parameter is filled in with a pointer to the next (uncompiled)
SQLite statement in the input string, if any.
The sqlite3_finalize() routine deallocates a prepared SQL statement.
The sqlite3_reset() routine resets a prepared SQL statement so that it
can be executed again.
</p>
<blockquote><pre>
int sqlite3_bind_blob(sqlite3_stmt*, int, const void*, int n, int eCopy);
int sqlite3_bind_blob(sqlite3_stmt*, int, const void*, int n, void(*)(void*));
int sqlite3_bind_double(sqlite3_stmt*, int, double);
int sqlite3_bind_int(sqlite3_stmt*, int, int);
int sqlite3_bind_int64(sqlite3_stmt*, int, long long int);
int sqlite3_bind_null(sqlite3_stmt*, int);
int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, int eCopy);
int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int n, int eCopy);
int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*));
int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int n, void(*)(void*));
int sqlite3_bind_value(sqlite3_stmt*, int, const sqlite3_value*);
</pre></blockquote>
@ -202,26 +247,38 @@ of the result set:
</p>
<blockquote><pre>
int sqlite3_column_count(sqlite3_stmt*);
int sqlite3_column_type(sqlite3_stmt*,int);
const char *sqlite3_column_decltype(sqlite3_stmt *, int i);
const char *sqlite3_column_decltype16(sqlite3_stmt *, int i);
const char *sqlite3_column_name(sqlite3_stmt*,int);
const void *sqlite3_column_name16(sqlite3_stmt*,int);
const void *sqlite3_column_blob(sqlite3_stmt*, int iCol);
int sqlite3_column_bytes(sqlite3_stmt*, int iCol);
int sqlite3_column_bytes16(sqlite3_stmt*, int iCol);
int sqlite3_column_count(sqlite3_stmt*);
const char *sqlite3_column_decltype(sqlite3_stmt *, int iCol);
const void *sqlite3_column_decltype16(sqlite3_stmt *, int iCol);
double sqlite3_column_double(sqlite3_stmt*, int iCol);
int sqlite3_column_int(sqlite3_stmt*, int iCol);
long long int sqlite3_column_int64(sqlite3_stmt*, int iCol);
const char *sqlite3_column_name(sqlite3_stmt*, int iCol);
const void *sqlite3_column_name16(sqlite3_stmt*, int iCol);
const unsigned char *sqlite3_column_text(sqlite3_stmt*, int iCol);
const void *sqlite3_column_text16(sqlite3_stmt*, int iCol);
int sqlite3_column_type(sqlite3_stmt*, int iCol);
</pre></blockquote>
<p>
The sqlite3_column_count() function returns the number of columns in
the results set. The sqlite3_column_type() function returns the
The
<a href="capi3ref.html#sqlite3_column_count">sqlite3_column_count()</a>
function returns the number of columns in
the results set. sqlite3_column_count() can be called at any time after
sqlite3_prepare().
<a href="capi3ref.html#sqlite3_data_count">sqlite3_data_count()</a>
works similarly to
sqlite3_column_count() except that it only works following sqlite3_step().
If the previous call to sqlite3_step() returned SQLITE_DONE or an error code,
then sqlite3_data_count() will return 0 whereas sqlite3_column_count() will
continue to return the number of columns in the result set.
</p>
<p>
The sqlite3_column_type() function returns the
datatype for the value in the Nth column. The return value is one
of these:
</p>
@ -252,6 +309,12 @@ sqlite3_column_int64() returns 64-bit INTEGER data.
Finally, sqlite3_column_double() return floating point data.
</p>
<p>
It is not necessary to retrieve data in the format specify by
sqlite3_column_type(). If a different format is requested, the data
is converted automatically.
</p>
<h4>2.3 User-defined functions</h4>
<p>
@ -265,7 +328,6 @@ User defined functions can be created using the following routine:
const char *zFunctionName,
int nArg,
int eTextRep,
int iCollateArg,
void*,
void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
void (*xStep)(sqlite3_context*,int,sqlite3_value**),
@ -276,16 +338,16 @@ User defined functions can be created using the following routine:
const void *zFunctionName,
int nArg,
int eTextRep,
int iCollateArg,
void*,
void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
void (*xStep)(sqlite3_context*,int,sqlite3_value**),
void (*xFinal)(sqlite3_context*)
);
#define SQLITE3_UTF8 1
#define SQLITE3_UTF16LE 2
#define SQLITE3_UTF16 2
#define SQLITE3_UTF16BE 3
#define SQLITE3_ANY 4
#define SQLITE3_UTF16LE 4
#define SQLITE3_ANY 5
</pre></blockquote>
<p>
@ -297,9 +359,6 @@ be one of the parameters defined above. SQLite version 3 allows multiple
implementations of the same function using different text representations.
The database engine chooses the function that minimization the number
of text conversions required.
The iCollateArg parameter indicates that the collating sequence for the
result is to be the same as the collating sequence of the iCollateArg-th
parameter.
</p>
<p>
@ -341,15 +400,15 @@ to report results:
<blockquote><pre>
void *sqlite3_aggregate_context(sqlite3_context*, int nbyte);
void *sqlite3_user_data(sqlite3_context*);
void sqlite3_result_blob(sqlite3_context*, const void*, int n, int eCopy);
void sqlite3_result_blob(sqlite3_context*, const void*, int n, void(*)(void*));
void sqlite3_result_double(sqlite3_context*, double);
void sqlite3_result_error(sqlite3_context*, const char*, int);
void sqlite3_result_error16(sqlite3_context*, const void*, int);
void sqlite3_result_int(sqlite3_context*, int);
void sqlite3_result_int64(sqlite3_context*, long long int);
void sqlite3_result_null(sqlite3_context*);
void sqlite3_result_text(sqlite3_context*, const char*, int n, int eCopy);
void sqlite3_result_text16(sqlite3_context*, const void*, int n, int eCopy);
void sqlite3_result_text(sqlite3_context*, const char*, int n, void(*)(void*));
void sqlite3_result_text16(sqlite3_context*, const void*, int n, void(*)(void*));
void sqlite3_result_value(sqlite3_context*, sqlite3_value*);
void *sqlite3_get_auxdata(sqlite3_context*, int);
void sqlite3_set_auxdata(sqlite3_context*, int, void*, void (*)(void*));

144
www/capi3ref.tcl
View File

@ -1,4 +1,4 @@
set rcsid {$Id: capi3ref.tcl,v 1.3 2004/06/12 00:42:36 danielk1977 Exp $}
set rcsid {$Id: capi3ref.tcl,v 1.4 2004/06/17 19:04:17 drh Exp $}
source common.tcl
header {C/C++ Interface For SQLite Version 3}
puts {
@ -43,8 +43,8 @@ api {result-codes} {
#define SQLITE_ROW 100 /* sqlite_step() has another row ready */
#define SQLITE_DONE 101 /* sqlite_step() has finished executing */
} {
The sqlite3.h header file defines macros for the integer result codes
returned by many API functions.
Many SQLite functions return an integer result code from the set shown
above in order to indicates success or failure.
}
api {} {
@ -76,8 +76,8 @@ api {} {
int sqlite3_bind_null(sqlite3_stmt*, int);
int sqlite3_bind_text(sqlite3_stmt*, int, const char*, int n, void(*)(void*));
int sqlite3_bind_text16(sqlite3_stmt*, int, const void*, int n, void(*)(void*));
#define SQLITE_STATIC ((void*)0)
#define SQLITE_EPHEMERAL ((void*)8)
#define SQLITE_STATIC ((void(*)(void *))0)
#define SQLITE_TRANSIENT ((void(*)(void *))-1)
} {
In the SQL strings input to sqlite3_prepare() and sqlite3_prepare16(),
one or more literals can be replace by a wildcard "?" or ":N:" where
@ -94,7 +94,7 @@ api {} {
text after SQLite has finished with it. If the fifth argument is the
special value SQLITE_STATIC, then the library assumes that the information
is in static, unmanaged space and does not need to be freed. If the
fifth argument has the value SQLITE_EPHEMERAL, then SQLite makes its
fifth argument has the value SQLITE_TRANSIENT, then SQLite makes its
on private copy of the data.
The sqlite3_bind_*() routine must be called after
@ -104,7 +104,7 @@ api {} {
}
api {} {
void sqlite3_busy_handler(sqlite*, int(*)(void*,int), void*);
int sqlite3_busy_handler(sqlite*, int(*)(void*,int), void*);
} {
This routine identifies a callback function that is invoked
whenever an attempt is made to open a database table that is
@ -129,7 +129,7 @@ api {} {
}
api {} {
void sqlite3_busy_timeout(sqlite*, int ms);
int sqlite3_busy_timeout(sqlite*, int ms);
} {
This routine sets a busy handler that sleeps for a while when a
table is locked. The handler will sleep multiple times until
@ -142,18 +142,19 @@ api {} {
}
api {} {
int sqlite3_changes(sqlite*);
int sqlite3_changes(sqlite*);
} {
This function returns the number of database rows that were changed
(or inserted or deleted) by the most recent called sqlite3_exec().
(or inserted or deleted) by the most recently completed
INSERT, UPDATE, or DELETE
statement. Only changes that are directly specified by the INSERT,
UPDATE, or DELETE statement are counted. Auxiliary changes caused by
triggers are not counted. Use the sqlite3_total_changes() function
to find the total number of changes including changes caused by triggers.
All changes are counted, even if they were later undone by a
ROLLBACK or ABORT. Except, changes associated with creating and
dropping tables are not counted.
If a callback invokes sqlite3_exec() recursively, then the changes
in the inner, recursive call are counted together with the changes
in the outer call.
Within the body of a trigger, the sqlite3_changes() function does work
to report the number of rows that were changed for the most recently
completed INSERT, UPDATE, or DELETE statement within the trigger body.
SQLite implements the command "DELETE FROM table" without a WHERE clause
by dropping and recreating the table. (This is much faster than going
@ -165,11 +166,39 @@ int sqlite3_changes(sqlite*);
}
api {} {
void sqlite3_close(sqlite *);
int sqlite3_total_changes(sqlite*);
} {
Call this function with a pointer to a structure that was previously
returned from sqlite3_open() or sqlite3_open16()
and the corresponding database will by closed.
This function returns the total number of database rows that have
be modified, inserted, or deleted since the database connection was
created using sqlite3_open(). All changes are counted, including
changes by triggers and changes to TEMP and auxiliary databases.
Except, changes to the SQLITE_MASTER table (caused by statements
such as CREATE TABLE) are not counted. Nor are changes counted when
an entire table is deleted using DROP TABLE.
See also the sqlite3_changes() API.
SQLite implements the command "DELETE FROM table" without a WHERE clause
by dropping and recreating the table. (This is much faster than going
through and deleting individual elements form the table.) Because of
this optimization, the change count for "DELETE FROM table" will be
zero regardless of the number of elements that were originally in the
table. To get an accurate count of the number of rows deleted, use
"DELETE FROM table WHERE 1" instead.
}
api {} {
int sqlite3_close(sqlite *);
} {
Call this function with a pointer to a structure that was previously
returned from sqlite3_open() or sqlite3_open16()
and the corresponding database will by closed.
SQLITE_OK is returned if the close is successful. If there are
prepared statements that have not been finalized, then SQLITE_BUSY
is returned. SQLITE_ERROR might be returned if the argument is not
a valid connection pointer returned by sqlite3_open() or if the connection
pointer has been closed previously.
}
api {} {
@ -229,16 +258,18 @@ int sqlite3_column_type(sqlite3_stmt*, int iCol);
api {} {
int sqlite3_column_count(sqlite3_stmt *pStmt);
} {
Return the number of columns in the result set returned by the compiled
Return the number of columns in the result set returned by the prepared
SQL statement. This routine returns 0 if pStmt is an SQL statement
that does not return data (for example an UPDATE).
See also sqlite3_data_count().
}
api {} {
const char *sqlite3_column_decltype(sqlite3_stmt *, int i);
const void *sqlite3_column_decltype16(sqlite3_stmt*,int);
} {
The first parameter is a compiled SQL statement. If this statement
The first parameter is a prepared SQL statement. If this statement
is a SELECT statement, the Nth column of the returned result set
of the SELECT is a table column then the declared type of the table
column is returned. If the Nth column of the result set is not at table
@ -266,38 +297,27 @@ api {} {
const char *sqlite3_column_name(sqlite3_stmt*,int);
const void *sqlite3_column_name16(sqlite3_stmt*,int);
} {
The first parameter is a compiled SQL statement. This function returns
The first parameter is a prepared SQL statement. This function returns
the column heading for the Nth column of that statement, where N is the
second function parameter. The string returned is UTF-8 for
sqlite3_column_name() and UTF-16 for sqlite3_column_name16().
}
api {} {
void *sqlite3_commit_hook(sqlite*, int(*)(void*), void*);
void *sqlite3_commit_hook(sqlite*, int(*xCallback)(void*), void *pArg);
} {
This routine configures a callback function - the progress callback - that
is invoked periodically during long running calls to sqlite3_exec(),
sqlite3_step() and sqlite3_get_table().
An example use for this API is to keep
a GUI updated during a large query.
<i>Experimental</i>
The progress callback is invoked once for every N virtual machine opcodes,
where N is the second argument to this function. The progress callback
itself is identified by the third argument to this function. The fourth
argument to this function is a void pointer passed to the progress callback
function each time it is invoked.
Register a callback function to be invoked whenever a new transaction
is committed. The pArg argument is passed through to the callback.
callback. If the callback function returns non-zero, then the commit
is converted into a rollback.
If a call to sqlite3_exec(), sqlite3_step() or sqlite3_get_table() results
in less than N opcodes being executed, then the progress callback is not
invoked.
To remove the progress callback altogether, pass NULL as the third
argument to this function.
If another function was previously registered, its pArg value is returned.
Otherwise NULL is returned.
If the progress callback returns a result other than 0, then the current
query is immediately terminated and any database changes rolled back. If the
query was part of a larger transaction, then the transaction is not rolled
back and remains active. The sqlite3_exec() call returns SQLITE_ABORT.
Registering a NULL function disables the callback. Only a single commit
hook callback can be registered at a time.
}
api {} {
@ -345,7 +365,9 @@ int sqlite3_create_collation16(
The third argument must be one of the constants SQLITE_UTF8,
SQLITE_UTF16LE or SQLITE_UTF16BE, indicating that the user-supplied
routine expects to be passed pointers to strings encoded using UTF-8,
UTF-16 little-endian or UTF-16 big-endian respectively.
UTF-16 little-endian or UTF-16 big-endian respectively. The
SQLITE_UTF16 constant indicates that text strings are expected in
UTF-16 in the native byte order of the host machine.
A pointer to the user supplied routine must be passed as the fifth
argument. If it is NULL, this is the same as deleting the collation
@ -404,7 +426,6 @@ int sqlite3_create_function(
const char *zFunctionName,
int nArg,
int eTextRep,
int iCollateArg,
void*,
void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
void (*xStep)(sqlite3_context*,int,sqlite3_value**),
@ -415,7 +436,6 @@ int sqlite3_create_function16(
const void *zFunctionName,
int nArg,
int eTextRep,
int iCollateArg,
void*,
void (*xFunc)(sqlite3_context*,int,sqlite3_value**),
void (*xStep)(sqlite3_context*,int,sqlite3_value**),
@ -443,7 +463,7 @@ int sqlite3_create_function16(
aggregate takes. If this parameter is negative, then the function or
aggregate may take any number of arguments.
The seventh, eighth and ninth parameters, xFunc, xStep and xFinal, are
The sixth, seventh and eighth, xFunc, xStep and xFinal, are
pointers to user implemented C functions that implement the user
function or aggregate. A scalar function requires an implementation of
the xFunc callback only, NULL pointers should be passed as the xStep
@ -464,7 +484,7 @@ int sqlite3_data_count(sqlite3_stmt *pStmt);
will return the same value as the sqlite3_column_count() function.
After sqlite3_step() has returned an SQLITE_DONE, SQLITE_BUSY or
error code, or before sqlite3_step() has been called on a
compiled SQL statement, this routine returns zero.
prepared SQL statement, this routine returns zero.
}
api {} {
@ -550,12 +570,15 @@ int sqlite3_exec(
api {} {
int sqlite3_finalize(sqlite3_stmt *pStmt);
} {
The sqlite3_finalize() function is called to delete a compiled
The sqlite3_finalize() function is called to delete a prepared
SQL statement obtained by a previous call to sqlite3_prepare()
or sqlite3_prepare16(). If the statement was executed successfully, or
not executed at all, then SQLITE_OK is returned. If execution of the
statement failed then an error code is returned.
All prepared statements must finalized before sqlite3_close() is
called or else the close will fail with a return code of SQLITE_BUSY.
This routine can be called at any point during the execution of the
virtual machine. If the virtual machine has not completed execution
when this routine is called, that is like encountering an error or
@ -637,12 +660,6 @@ api {sqlite3_interrupt} {
immediately.
} {}
api {} {
int sqlite3_last_statement_changes(sqlite*);
} {
Experimental
}
api {} {
long long int sqlite3_last_insert_rowid(sqlite*);
} {
@ -810,7 +827,7 @@ void sqlite3_progress_handler(sqlite*, int, int(*)(void*), void*);
api {} {
int sqlite3_reset(sqlite3_stmt *pStmt);
} {
The sqlite3_reset() function is called to reset a compiled SQL
The sqlite3_reset() function is called to reset a prepared SQL
statement obtained by a previous call to sqlite3_prepare() or
sqlite3_prepare16() back to it's initial state, ready to be re-executed.
Any SQL statement variables that had values bound to them using
@ -834,6 +851,10 @@ void sqlite3_result_value(sqlite3_context*, sqlite3_value*);
User-defined functions invoke the following routines in order to
set their return value. The sqlite3_result_value() routine is used
to return an exact copy of one of the parameters to the function.
The operation of these routines is very similar to the operation of
sqlite3_bind_blob() and its cousins. Refer to the documentation there
for additional information.
}
api {} {
@ -842,7 +863,6 @@ int sqlite3_set_authorizer(
int (*xAuth)(void*,int,const char*,const char*,const char*,const char*),
void *pUserData
);
#define SQLITE_COPY 0 /* Table Name File Name */
#define SQLITE_CREATE_INDEX 1 /* Index Name Table Name */
#define SQLITE_CREATE_TABLE 2 /* Table Name NULL */
#define SQLITE_CREATE_TEMP_INDEX 3 /* Index Name Table Name */
@ -896,7 +916,7 @@ int sqlite3_set_authorizer(
api {} {
int sqlite3_step(sqlite3_stmt*);
} {
After an SQL query has been compiled with a call to either
After an SQL query has been prepared with a call to either
sqlite3_prepare() or sqlite3_prepare16(), then this function must be
called one or more times to execute the statement.
@ -994,12 +1014,14 @@ for {set j 0} {$j<3} {incr j} {
puts {<ul>}
while {$i<$limit && $i<$n} {
set name $sname($i)
puts "<li><a href=\"#$name\">$name</a></li>"
if {[regexp {^sqlite} $name]} {set display $name} {set display <i>$name</i>}
puts "<li><a href=\"#$name\">$display</a></li>"
incr i
}
puts {</ul></td>}
}
puts "</table>"
puts "<!-- $n entries. $nrow rows in 3 columns -->"
proc resolve_name {ignore_list name} {
global name_to_idx

6
www/datatype3.tcl
View File

@ -1,4 +1,4 @@
set rcsid {$Id: datatype3.tcl,v 1.5 2004/06/10 10:51:53 danielk1977 Exp $}
set rcsid {$Id: datatype3.tcl,v 1.6 2004/06/17 19:04:17 drh Exp $}
source common.tcl
header {Datatypes In SQLite Version 3}
puts {
@ -309,8 +309,8 @@ instead of memcmp().
</p>
<p>
Aside from the default collation sequence BINARY, implemented using
memcmp(), SQLite features two extra built-in collation sequences,
NOCASE and REVERSE:
memcmp(), SQLite features two extra built-in collation sequences
intended for testing purposes, NOCASE and REVERSE:
</p>
<UL>
<LI><b>BINARY</b> - Compares string data using memcmp(), regardless

5
www/docs.tcl
View File

@ -1,7 +1,7 @@
# This script generates the "docs.html" page that describes various
# sources of documentation available for SQLite.
#
set rcsid {$Id: docs.tcl,v 1.4 2004/06/11 17:48:04 drh Exp $}
set rcsid {$Id: docs.tcl,v 1.5 2004/06/17 19:04:17 drh Exp $}
source common.tcl
header {SQLite Documentation}
puts {
@ -28,6 +28,9 @@ doc {Version 2 C/C++ API} {c_interface.html} {
A description of the C/C++ interface bindings for SQLite through version
2.8
}
doc {SQLite Version 3} {version3.html} {
A summary of of the changes between SQLite version 2.8 and SQLite version 3.0.
}
doc {Version 3 C/C++ API} {capi3.html} {
A description of the C/C++ interface bindings for SQLite version 3.0.0
and following.

7
www/index.tcl
View File

@ -60,13 +60,14 @@ proc newsitem {date title text} {
newsitem {2004-Jun-18} {Version 3.0.0 (alpha) Released} {
The first alpha release of SQLite version 3.0 is available for
public review and comment. Version 3.0 enhances i18n support
public review and comment. Version 3.0 enhances internationalization support
through the use of UTF-16 and user-defined text collating sequences.
BLOBs can now be stored directly, without encoding.
A new file format results in databases that are 25% smaller (depending
on content). The code is also a little faster. In spite of the many
new features, the library footprint is still less than 235KB
new features, the library footprint is still less than 240KB
(x86, gcc -O1).
<a href="version3.html">Additional information</a>.
Our intent is to freeze the file format and API on 2004-Jul-01.
Users are encouraged to review and evaluate this alpha release carefully
@ -87,4 +88,4 @@ puts {
<p align="right"><a href="oldnews.html">Old news...</a></p>
</td></tr></table>
}
footer {$Id: index.tcl,v 1.87 2004/06/16 03:02:04 drh Exp $}
footer {$Id: index.tcl,v 1.88 2004/06/17 19:04:17 drh Exp $}

142
www/lang.tcl
View File

@ -1,7 +1,7 @@
#
# Run this Tcl script to generate the sqlite.html file.
#
set rcsid {$Id: lang.tcl,v 1.68 2004/05/31 15:06:30 drh Exp $}
set rcsid {$Id: lang.tcl,v 1.69 2004/06/17 19:04:17 drh Exp $}
source common.tcl
header {Query Language Understood by SQLite}
puts {
@ -129,9 +129,10 @@ temporary tables. These cannot be detached. Attached databases
are removed using the <a href="#detach">DETACH DATABASE</a>
statement.</p>
<p>You can read from and write to an attached database, but you cannot
alter the schema of an attached database. You can only CREATE and
DROP in the original database.</p>
<p>You can read from and write to an attached database and you
can modify the schema of the attached database. This is a new
feature of SQLite version 3.0. In SQLite 2.8, schema changes
to attached databases were not allows.</p>
<p>You cannot create a new table with the same name as a table in
an attached database, but you can attach a database which contains
@ -147,25 +148,28 @@ of that name. Any tables of that name attached afterwards require the table
prefix. If the 'default' table of a given name is detached, then
the last table of that name attached becomes the new default.</p>
<p>When there are attached databases, transactions are not atomic.
Transactions continue to be atomic within each individual
database file. But if your machine crashes in the middle
of a COMMIT where you have updated two or more database
files, some of those files might get the changes where others
might not.</p>
<p>
Transactions involving multiple attached databases are atomic,
assuming that the main database is not ":memory:". If the main
database is ":memory:" then
transactions continue to be atomic within each individual
database file. But if the host computer crashes in the middle
of a COMMIT where two or more database files are updated,
some of those files might get the changes where others
might not.
Atomic commit of attached databases is a new feature of SQLite version 3.0.
In SQLite version 2.8, all commits to attached databases behaved as if
the main database were ":memory:".
</p>
<p>There is a compile-time limit of 10 attached database files.</p>
<p>Executing a BEGIN TRANSACTION statement locks all database
files, so this feature cannot (currently) be used to increase
concurrancy.</p>
}
Section {BEGIN TRANSACTION} transaction
Syntax {sql-statement} {
BEGIN [TRANSACTION [<name>]] [ON CONFLICT <conflict-algorithm>]
BEGIN [TRANSACTION [<name>]]
}
Syntax {sql-statement} {
END [TRANSACTION [<name>]]
@ -183,8 +187,7 @@ rollback and atomic commit. See <a href="#attach">ATTACH</a> for
an exception when there are attached databases.</p>
<p>The optional transaction name is ignored. SQLite currently
doesn't allow nested transactions. Attempting to start a new
transaction inside another is an error.</p>
does not allow nested transactions.</p>
<p>
No changes can be made to the database except within a transaction.
@ -206,14 +209,18 @@ conflict resolution algorithm.
</p>
<p>
The optional ON CONFLICT clause at the end of a BEGIN statement
can be used to changed the default conflict resolution algorithm.
The normal default is ABORT. If an alternative is specified by
the ON CONFLICT clause of a BEGIN, then that alternative is used
as the default for all commands within the transaction. The default
algorithm is overridden by ON CONFLICT clauses on individual
constraints within the CREATE TABLE or CREATE INDEX statements
and by the OR clauses on COPY, INSERT, and UPDATE commands.
The COMMIT command does not actually perform a commit until all
pending SQL commands finish. Thus if two or more SELECT statements
are in the middle of processing and a COMMIT is executed, the commit
will not actually occur until all SELECT statements finish.
</p>
<p>
An attempt to execute COMMIT might result in an SQLITE_BUSY return code.
This indicates that another thread or process had a read lock on the database
that prevented the database from being updated. When COMMIT fails in this
way, the transaction remains active and the COMMIT can be retried later
after the reader has had a chance to clear.
</p>
}
@ -251,6 +258,11 @@ COPY [ OR <conflict-algorithm> ] [<database-name> .] <table-name> FROM <filename
}
puts {
<p>The COPY command is available in SQLite version 2.8 and earlier.
The COPY command has been removed from SQLite version 3.0 due to
complications in trying to support it in a mixed UTF-8/16 environment.
</p>
<p>The COPY command is an extension used to load large amounts of
data into a table. It is modeled after a similar command found
in PostgreSQL. In fact, the SQLite COPY command is specifically
@ -290,7 +302,7 @@ CREATE [UNIQUE] INDEX <index-name>
ON [<database-name> .] <table-name> ( <column-name> [, <column-name>]* )
[ ON CONFLICT <conflict-algorithm> ]
} {column-name} {
<name> [ ASC | DESC ]
<name> [ COLLATE <collation-name>] [ ASC | DESC ]
}
puts {
@ -302,6 +314,12 @@ Each column name can be followed by one of the "ASC" or "DESC" keywords
to indicate sort order, but the sort order is ignored in the current
implementation. Sorting is always done in ascending order.</p>
<p>The COLLATE clause following each column name defines a collating
sequence used for text entires in that column. The default collating
sequence is the collating sequence defined for that column in the
CREATE TABLE statement. Or if no collating sequence is otherwise defined,
the built-in BINARY collating sequence is used.</p>
<p>There are no arbitrary limits on the number of indices that can be
attached to a single table, nor on the number of columns in an index.</p>
@ -353,7 +371,8 @@ NOT NULL [ <conflict-clause> ] |
PRIMARY KEY [<sort-order>] [ <conflict-clause> ] |
UNIQUE [ <conflict-clause> ] |
CHECK ( <expr> ) [ <conflict-clause> ] |
DEFAULT <value>
DEFAULT <value> |
COLLATE <collation-name>
} {constraint} {
PRIMARY KEY ( <column-list> ) [ <conflict-clause> ] |
UNIQUE ( <column-list> ) [ <conflict-clause> ] |
@ -379,6 +398,9 @@ The UNIQUE constraint causes an index to be created on the specified
columns. This index must contain unique keys.
The DEFAULT constraint
specifies a default value to use when doing an INSERT.
The COLLATE clause specifies what text collating function to use
when comparing text entries for the column. The built-in BINARY
collating function is used by default.
</p>
<p>Specifying a PRIMARY KEY normally just creates a UNIQUE index
@ -1246,14 +1268,6 @@ is returned it is as an integer.</p>
the <a href="#pragma_default_cache_size"><b>default_cache_size</b></a>
pragma to check the cache size permanently.</p></li>
<li><p><b>PRAGMA count_changes = ON; </b>(1)<b>
<br>PRAGMA count_changes = OFF;</b> (0)</p>
<p>When on, the COUNT_CHANGES pragma causes the callback function to
be invoked once for each DELETE, INSERT, or UPDATE operation. The
argument is the number of rows that were changed.</p>
<p>This pragma may be removed from future versions of SQLite.
Consider using the <b>sqlite_changes()</b> API function instead.</p></li>
<li><p><b>PRAGMA database_list;</b></p>
<p>For each open database, invoke the callback function once with
information about that database. Arguments include the index and
@ -1336,30 +1350,12 @@ is returned it is as an integer.</p>
<a href="#pragma_temp_store"><b>temp_store</b></a> pragma to change the
temp_store mode for the current session.</p></li>
<a name="pragma_empty_result_callbacks"></a>
<li><p><b>PRAGMA empty_result_callbacks = ON; </b>(1)<b>
<br>PRAGMA empty_result_callbacks = OFF;</b> (0)</p>
<p>When on, the EMPTY_RESULT_CALLBACKS pragma causes the callback
function to be invoked once for each query that has an empty result
set. The third "<b>argv</b>" parameter to the callback is set to NULL
because there is no data to report. But the second "<b>argc</b>" and
fourth "<b>columnNames</b>" parameters are valid and can be used to
determine the number and names of the columns that would have been in
the result set had the set not been empty.</p></li>
<li><p><b>PRAGMA foreign_key_list(</b><i>table-name</i><b>);</b></p>
<p>For each foreign key that references a column in the argument
table, invoke the callback function with information about that
foreign key. The callback function will be invoked once for each
column in each foreign key.</p></li>
<li><p><b>PRAGMA full_column_names = ON; </b>(1)<b>
<br>PRAGMA full_column_names = OFF;</b> (0)</p>
<p>The column names reported in an SQLite callback are normally just
the name of the column itself, except for joins when "TABLE.COLUMN"
is used. But when full_column_names is turned on, column names are
always reported as "TABLE.COLUMN" even for simple queries.</p></li>
<li><p><b>PRAGMA index_info(</b><i>index-name</i><b>);</b></p>
<p>For each column that the named index references, invoke the
callback function
@ -1387,39 +1383,6 @@ is returned it is as an integer.</p>
This only works if the library is compiled without the NDEBUG macro.
</p></li>
<a name="pragma_show_datatypes"></a>
<li><p><b>PRAGMA show_datatypes = ON; </b>(1)<b>
<br>PRAGMA show_datatypes = OFF;</b> (0)</p>
<p>When turned on, the SHOW_DATATYPES pragma causes extra entries containing
the names of <a href="datatypes.html">datatypes</a> of columns to be
appended to the 4th ("columnNames") argument to <b>sqlite_exec()</b>
callbacks. When
turned off, the 4th argument to callbacks contains only the column names.
The datatype for table columns is taken from the CREATE TABLE statement
that defines the table. Columns with an unspecified datatype have a
datatype of "NUMERIC" and the results of expression have a datatype of
either "TEXT" or "NUMERIC" depending on the expression.
The following chart illustrates the difference for the query
"SELECT 'xyzzy', 5, NULL AS empty ":</p>
<blockquote><table border=0>
<tr><th>show_datatypes=OFF</th><th width=30></th>
<th>show_datatypes=ON</th></tr>
<tr><td valign="top">
azCol[0] = "xyzzy";<br>
azCol[1] = "5";<br>
azCol[2] = "empty";<br>
azCol[3] = 0;
</td><td></td><td valign="top">
azCol[0] = "xyzzy";<br>
azCol[1] = "5";<br>
azCol[2] = "empty";<br>
azCol[3] = "TEXT";<br>
azCol[4] = "NUMERIC";<br>
azCol[5] = "TEXT";<br>
azCol[6] = 0;
</td></table></blockquote></li>
<a name="pragma_synchronous"></a>
<li><p><b>PRAGMA synchronous;
<br>PRAGMA synchronous = FULL; </b>(2)<b>
@ -1513,7 +1476,7 @@ STAR | <table-name> . STAR | <expr> [ [AS] <string> ]
} {sort-expr-list} {
<expr> [<sort-order>] [, <expr> [<sort-order>]]*
} {sort-order} {
ASC | DESC
[ COLLATE <collation-name> ] [ ASC | DESC ]
} {compound_op} {
UNION | UNION ALL | INTERSECT | EXCEPT
}
@ -1561,8 +1524,9 @@ The argument to ORDER BY is a list of expressions that are used as the
key for the sort. The expressions do not have to be part of the
result for a simple SELECT, but in a compound SELECT each sort
expression must exactly match one of the result columns. Each
sort expression may be optionally followed by ASC or DESC to specify
the sort order.</p>
sort expression may be optionally followed by a COLLATE keyword and
the name of a collating function used for ordering text and/or
keywords ASC or DESC to specify the sort order.</p>
<p>The LIMIT clause places an upper bound on the number of rows
returned in the result. A negative LIMIT indicates no upper bound.

285
www/version3.tcl Normal file
View File

@ -0,0 +1,285 @@
#!/usr/bin/tclsh
source common.tcl
header {SQLite Version 3 Overview}
puts {
<h2>SQLite Version 3 Overview</h2>
<p>
SQLite version 3.0 introduces important changes to the library, including:
</p>
<ul>
<li>A more compact format for database files.</li>
<li>Manifest typing and BLOB support.</li>
<li>Support for both UTF-8 and UTF-16 text.</li>
<li>User-defined text collating sequences.</li>
<li>64-bit ROWIDs.</li>
<li>Improved Concurrency.</li>
</ul>
<p>
This document is a quick introduction to the changes for SQLite 3.0
for users who are already familiar with SQLite version 2.8.
</p>
<h3>Naming Changes</h3>
<p>
SQLite version 2.8 will continue to be supported with bug fixes
for the foreseeable future. In order to allow SQLite version 2.8
and SQLite version 3.0 to peacefully coexist, the names of key files
and APIs in SQLite version 3.0 have been changed to include the
character "3". For example, the include file used by C programs
has been changed from "sqlite.h" to "sqlite3.h". And the name of
the shell program used to interact with databases has been changed
from "sqlite.exe" to "sqlite3.exe". With these changes, it is possible
to have both SQLite 2.8 and SQLite 3.0 installed on the same system at
the same time. And it is possible for the same C program to link
against both SQLite 2.8 and SQLite 3.0 at the same time and to use
both libraries at the same time.
</p>
<h3>New File Format</h3>
<p>
The format used by SQLite database files has been completely revised.
The old version 2.1 format and the new 3.0 format are incompatible with
one another. Version 2.8 of SQLite will not read and version 3.0 database
files and version 3.0 of SQLite will not read a version 2.8 database file.
</p>
<p>
To convert an SQLite 2.8 database into an SQLite 3.0 database, have
ready the command-line shells for both version 2.8 and 3.0. Then
enter a command like the following:
</p>
<blockquote><pre>
sqlite OLD.DB .dump | sqlite3 NEW.DB
</pre></blockquote>
<p>
The new database file format uses B+Trees for tables. In a B+Tree, all
data is stored in the leaves of the tree instead of in both the leaves and
the intermediate branch nodes. The use of B+Trees for tables allows for
better scalability and the storage larger data fields without the use of
overflow pages. Traditional B-Trees are still used for indices.</p>
<p>
The new file format also supports variable pages sizes between 512 and
65536 bytes. The size of a page is stored in the file header so the
same library can read databases with different pages sizes, in theory,
though this feature has not yet been implemented in practice.
</p>
<p>
The new file format omits unused fields from its disk images. For example,
indices use only the key part of a B-Tree record and not the data. So
for indices, the field that records the length of the data is omitted.
Integer values such as the length of key and data are stored using
a variable-length encoding so that only one or two bytes are required to
store the most common cases but up to 64-bits of information can be encoded
if needed.
Integer and floating point data is stored on the disk in binary rather
than being converted into ASCII as in SQLite version 2.8.
These changes taken together result in database files that are typically
25% to 35% smaller than the equivalent files in SQLite version 2.8.
</p>
<p>
Details of the low-level B-Tree format used in SQLite version 3.0 can
be found in header comments to the
<a href="http://www.sqlite.org/cvstrac/getfile/sqlite/src/btree.c">btree.c</a>
source file.
</p>
<h3>Manifest Typing and BLOB Support</h3>
<p>
SQLite version 2.8 will deal with data in various formats internally,
but when writing to the disk or interacting through its API, SQLite 2.8
always converts data into ASCII text. SQLite 3.0, in contrast, exposes
its internal data representations to the user and stores binary representations
to disk when appropriate. The exposing of non-ASCII representations was
added in order to support BLOBs.
</p>
<p>
SQLite version 2.8 had the feature that any type of data could be stored
in any table column regardless of the declared type of that column. This
feature is retained in version 3.0, though in a slightly modified form.
Each table column will store any type of data, though columns have an
affinity for the format of data defined by their declared datatype.
When data is inserted into a column, that column will make at attempt
to convert the data format into the columns declared type. All SQL
database engines do this. The difference is that SQLite 3.0 will
still store the data even if a format conversion is not possible.
</p>
<p>
For example, if you have a table column declared to be of type "INTEGER"
and you try to insert a string, the column will look at the text string
and see if it looks like a number. If the string does look like a number
it is converted into a number and into an integer if the number does not
have a fractional part, and stored that way. But if the string is not
a well-formed number it is still stored as a string. A column with a
type of "TEXT" tries to convert numbers into an ASCII-Text representation
before storing them. But BLOBs are stored in TEXT columns as BLOBs because
you cannot in general convert a BLOB into text.
</p>
<p>
In most other SQL database engines the datatype is associated with
the table column the holds the data - with the data container.
In SQLite 3.0, the datatype is associated with the data itself, not
with its container.
<a href="http://www.paulgraham.com/">Paul Graham</a> in his book
<a href="http://www.paulgraham.com/acl.html"><i>ANSI Common Lisp</i></a>
calls this property "Manifest Typing".
Other writers have other definitions for the term "manifest typing",
so beware of confusion. But by whatever name, that is the datatype
model supported by SQLite 3.0.
</p>
<p>
Additional information about datatypes in SQLite version 3.0 is
available
<a href="datatype3.html">separately</a>.
</p>
<h3>Support for UTF-8 and UTF-16</h3>
<p>
The new API for SQLite 3.0 contains routines that accept text as
both UTF-8 and UTF-16 in the native byte order of the host machine.
Each database file manages text as either UTF-8, UTF-16BE (big-endian),
or UTF-16LE (little-endian). Internally and in the disk file, the
same text representation is used everywhere. If the text representation
specified by the database file (in the file header) does not match
the text representation required by the interface routines, then text
is converted on-the-fly.
Constantly converting text from one representation to another can be
computationally expensive, so it is suggested that programmers choose a
single representation and stick with it throughout their application.
</p>
<p>
In the current implementation of SQLite, the SQL parser only works
with UTF-8 text. So if you supply UTF-16 text it will be converted.
This is just an implementation issue and there is nothing to prevent
future versions of SQLite from parsing UTF-16 encoded SQL natively.
</p>
<p>
When creating new user-defined SQL functions and collating sequences,
each function or collating sequence can specify it if works with
UTF-8, UTF-16be, or UTF-16le. Separate implementations can be registered
for each encoding. If an SQL function or collating sequences is required
but a version for the current text encoding is not available, then
the text is automatically converted. As before, this conversion takes
computation time, so programmers are advised to pick a single
encoding and stick with it in order to minimize the amount of unnecessary
format juggling.
</p>
<p>
SQLite is not particular about the text it receives and is more than
happen to process text strings that are not normalized or even
well-formed UTF-8 or UTF-16. Thus, programmers who want to store
IS08859 data can do so using the UTF-8 interfaces. As long as no
attempts are made to use a UTF-16 collating sequence or SQL function,
the byte sequence of the text will not be modified in any way.
</p>
<h3>User-defined Collating Sequences</h3>
<p>
A collating sequence is just a defined order for text. When SQLite 3.0
sorts (or uses a comparison operator like "<" or ">=") the sort order
is first determined by the data type.
</p>
<ul>
<li>NULLs sort first</li>
<li>Numeric values sort next in numerical order</li>
<li>Text values come after numerics</li>
<li>BLOBs sort last</li>
</ul>
<p>
Collating sequences are used for comparing two text strings.
The collating sequence does not change the ordering of NULLs, numbers,
or BLOBs, only text.
</p>
<p>
A collating sequence is implemented as a function that takes the
two strings being compared as inputs and returns negative, zero, or
positive if the first string is less than, equal to, or greater than
the first.
SQLite 3.0 comes with a single built-in collating sequence named "BINARY"
which is implemented using the memcmp() routine from the standard C library.
The BINARY collating sequence works well for English text. For other
languages or locales, alternative collating sequences may be preferred.
</p>
<p>
The decision of which collating sequence to use is controlled by the
COLLATE clause in SQL. A COLLATE clause can occur on a table definition,
to define a default collating sequence to a table column, or on field
of an index, or in the ORDER BY clause of a SELECT statement.
Planned enhancements to SQLite are to include standard CAST() syntax
to allow the collating sequence of an expression to be defined.
</p>
<h3>64-bit ROWIDs</h3>
<p>
Every row of a table has a unique rowid.
If the table defines a column with the type "INTEGER PRIMARY KEY" then that
column becomes an alias for the rowid. But with or without an INTEGER PRIMARY
KEY column, every row still has a rowid.
</p>
<p>
In SQLite version 3.0, the rowid is a 64-bit signed integer.
This is an expansion of SQLite version 2.8 which only permitted
rowids of 32-bits.
</p>
<p>
To minimize storage space, the 64-bit rowid is stored as a variable length
integer. Rowids between 0 and 127 use only a single byte.
Rowids between 0 and 16383 use just 2 bytes. Up to 2097152 uses three
bytes. And so forth. Negative rowids are allowed but they always use
nine bytes of storage and so their use is discouraged. When rowids
are generated automatically by SQLite, they will always be non-negative.
</p>
<h3>Improved Concurrency</h3>
<p>
SQLite version 2.8 allowed multiple simultaneous readers or a single
writer but not both. SQLite version 3.0 allows one process to begin
writing the database while other processes continue to read. The
writer must still obtain an exclusive lock on the database for a brief
interval in order to commit its changes, but the exclusive lock is no
longer required for the entire write operation.
A <a href="lockingv3.html">more detailed report</a> on the locking
behavior of SQLite version 3.0 is available separately.
</p>
<p>
A limited form of table-level locking is now also available in SQLite.
If each table is stored in a separate database file, those separate
files can be attached to the main database (using the ATTACH command)
and the combined databases will function as one. But locks will only
be acquired on individual files as needed. So if you redefine "database"
to mean two or more database files, then it is entirely possible for
two processes to be writing to the same database at the same time.
To further support this capability, commits of transactions involving
two or more ATTACHed database are now atomic.
</p>
}
footer {$Id: version3.tcl,v 1.1 2004/06/17 19:04:17 drh Exp $}