From: drh Date: Thu, 8 Jun 2000 21:53:06 +0000 (+0000) Subject: :-) (CVS 86) X-Git-Tag: version-3.6.10~6014 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=88923560db964322997ed4758477d22438ae8024;p=thirdparty%2Fsqlite.git :-) (CVS 86) FossilOrigin-Name: 049abcb37def4200fb8f4ad7cea60a1d53ee3219 --- diff --git a/Makefile.in b/Makefile.in index c0ec4641c7..a986a75c07 100644 --- a/Makefile.in +++ b/Makefile.in @@ -185,6 +185,9 @@ changes.html: $(TOP)/www/changes.tcl fileformat.html: $(TOP)/www/fileformat.tcl tclsh $(TOP)/www/fileformat.tcl >fileformat.html +lang.html: $(TOP)/www/lang.tcl + tclsh $(TOP)/www/lang.tcl >lang.html + # Files to be published on the website. # PUBLISH = \ @@ -193,6 +196,7 @@ PUBLISH = \ sqlite.html \ changes.html \ fileformat.html \ + lang.html \ c_interface.html website: $(PUBLISH) diff --git a/manifest b/manifest index db1dc48160..e69719a409 100644 --- a/manifest +++ b/manifest @@ -1,7 +1,7 @@ -C :-)\s(CVS\s85) -D 2000-06-08T19:43:40 +C :-)\s(CVS\s86) +D 2000-06-08T21:53:06 F COPYRIGHT 74a8a6531a42e124df07ab5599aad63870fa0bd4 -F Makefile.in 078af767c0d9e00d47b5d2b6e7677a10445d7057 +F Makefile.in c98978c886b94cf0d0ed414d6384501390cf0030 F README 51f6a4e7408b34afa5bc1c0485f61b6a4efb6958 F configure 00a5b5c82147a576fa6e82d7c1b0d55c321d6d2c x F configure.in 6ccfd5fc80517f7cfe605a7fc7e0f62d962a233c @@ -57,8 +57,9 @@ F www/c_interface.tcl 9ac800854272db5fe439e07b7435b243a5422293 F www/changes.tcl 04e66b4257589ff78a7e1de93e9dda4725fb03d6 F www/fileformat.tcl b11435fcd2cf2238a1c5e6d16fe5e83bcd14d434 F www/index.tcl b2c288000f14383501b157a57ee4506561d62f45 +F www/lang.tcl 2abf9ac0384b999c0c3f9752596abe8f8db7b2eb F www/sqlite.tcl 5420eab24b539928f80ea9b3088e2549d34f438d -P 57dce04addf6389a0e2b723aea47da6a54bff14e -R e3101b8e11471d082004499e06da77ef +P 8b1c151b7b2243672a0bf0ac8377e82c568bacfb +R 6dab3d7551f8822711ca5b84a3310ca7 U drh -Z 5656db42fbf878ca536962d55bd14a41 +Z 1919fdb42862a0c5cf9947137480de24 diff --git a/manifest.uuid b/manifest.uuid index 23ef52d5ea..aee3426948 100644 --- a/manifest.uuid +++ b/manifest.uuid @@ -1 +1 @@ -8b1c151b7b2243672a0bf0ac8377e82c568bacfb \ No newline at end of file +049abcb37def4200fb8f4ad7cea60a1d53ee3219 \ No newline at end of file diff --git a/www/lang.tcl b/www/lang.tcl new file mode 100644 index 0000000000..4770314dba --- /dev/null +++ b/www/lang.tcl @@ -0,0 +1,188 @@ +# +# Run this Tcl script to generate the sqlite.html file. +# +set rcsid {$Id: lang.tcl,v 1.1 2000/06/08 21:53:06 drh Exp $} + +puts { + + Query Language Understood By SQLite + + +

+SQL As Understood By SQLite +

} +puts "

+(This page was last modified on [lrange $rcsid 3 4] GMT) +

" + +puts { +

The SQLite library understands most of the standard SQL +language. But it does omit some features while at the same time +adding a few features of its own. This document attempts to +describe percisely what parts of the SQL language SQLite does +and does not support.

+ +

In all of the syntax diagrams that follow, literal text is shown in +bold blue. Non-terminal symbols are shown in italic red. Operators +that are part of the syntactic markup itself are shown in black roman.

+ +

This document is just an overview of the SQL syntax implemented +by SQLite. Many low-level productions are omitted. For detailed information +on the language that SQLite understands, refer to the source code.

+ +

CREATE TABLE

+ +

The basic structure of a CREATE TABLE statement is as follows:

+} + +proc Syntax {args} { + puts {} + foreach {rule body} $args { + puts "" + regsub -all < $body {%LT} body + regsub -all > $body {%GT} body + regsub -all %LT $body {} body + regsub -all %GT $body {} body + regsub -all {[]|[*?]} $body {&} body + regsub -all "\n" [string trim $body] "
\n" body + regsub -all "\n *" $body "\n\\ \\ \\ \\ " body + regsub -all {[|,*()]} $body {&} body + puts "" + } + puts {

" + puts "$rule ::=

$body

} +} + +Syntax {sql-command} { +CREATE TABLE ( + [, ]* + [, ]* +) +} {column-def} { + []* +} {type} { + | + ( ) | + ( , ) +} {column-constraint} { +NOT NULL | +PRIMARY KEY [] | +UNIQUE | +CHECK ( ) +} {constraint} { +PRIMARY KEY ( [, ]* ) | +UNIQUE ( [, ]* ) | +CHECK ( ) +} + +puts { +
A CREATE TABLE statement is basically the keywords "CREATE TABLE" +followed by the name of a new table and a parenthesized list of column +definitions and constraints. The table name can be either an identifier +or a string. The only reserved table name is "sqlite_master" which +is the name of the table that records the database schema.
+ +
Each column definition is the name of the column followed by the +datatype for that column, then one or more optional column constraints. +The datatype for the column is ignored. All information +is stored as null-terminated strings. The constraints are also ignored, +except that the PRIMARY KEY constraint will cause an index to be automatically +created that implements the primary key. The name of the primary +key index will be the table name +with "__primary_key" appended. The index used for a primary key +does not show up in the sqlite_master table, but a GDBM file is +created for that index.
+ +
There are no arbitrary limits on the size of columns, on the number +of columns, or on the number of constraints in a table.
+ +
The exact text +of each CREATE TABLE statement is stored in the sqlite_master +table. Everytime the database is opened, all CREATE TABLE statements +are read from the sqlite_master table and used to regenerate +SQLite's internal representation of the table layout.
+} + +puts {
CREATE INDEX
+} + +Syntax {sql-statement} { +CREATE INDEX +ON ( [, ]* ) +} {column-name} { + [ ASC | DESC ] +} + +puts { +
The CREATE INDEX command consists of the keywords "CREATE INDEX" followed +by the name of the new index, the keyword "ON" the name of a previously +created table that is to be indexed, and a parenthesized list of names of +columns in the table that are used for the index key. +Each column name can be followed by one of the "ASC" or "DESC" keywords +to indicate sort order, but since GDBM does not implement ordered keys, +these keywords are ignored.
+ +
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.
+ +
The exact text +of each CREATE INDEX statement is stored in the sqlite_master +table. Everytime the database is opened, all CREATE INDEX statements +are read from the sqlite_master table and used to regenerate +SQLite's internal representation of the index layout.
+ +
DROP TABLE
+} + +Syntax {sql-command} { +DROP TABLE +} + +puts { +
The DROP TABLE statement consists of the keywords "DROP TABLE" followed +by the name of the table. The table named is completely removed from +the disk. The table can not be recovered. All indices associated with +the table are also reversibly deleted.
+ +
DROP INDEX
+} + +Syntax {sql-command} { +DROP INDEX +} + +puts { +
The DROP INDEX statement consists of the keywords "DROP INDEX" followed +by the name of the index. The index named is completely removed from +the disk. The only way to recover the index is to reenter the +appropriate CREATE INDEX command.
+ +
VACUUM
+} + +Syntax {sql-statement} { +VACUUM [] +} + +puts { +
The VACUUM command is an SQLite extension modelled after a similar +command found in PostgreSQL. If VACUUM is invoked with the name of a +table or index, then the gdbm_reorganize() function is called +on the corresponding GDBM file. If VACUUM is invoked with no arguments, +then gdbm_reorganize() is call on every GDBM file in the database.
+ +
It is a good idea to run VACUUM after creating large indices, +especially indices where a single index value refers to many +entries in the data table. Reorganizing these indices will make +the underlying GDBM file much smaller and will help queries to +run much faster.
+ +} + +puts { +
+
+Back to the SQLite Home Page +
+ +}