diff options
author | dan miller | 2007-10-20 02:49:29 +0000 |
---|---|---|
committer | dan miller | 2007-10-20 02:49:29 +0000 |
commit | e36d23a85ebff914d74bb541558c2b6082b78edb (patch) | |
tree | 54b58fdf162e78af64055282a6035c8d2443389d /libraries/sqlite/unix/sqlite-3.5.1/www/lang.tcl | |
parent | * Fixed an issue whereby avatar chat distances were being calculated against ... (diff) | |
download | opensim-SC-e36d23a85ebff914d74bb541558c2b6082b78edb.zip opensim-SC-e36d23a85ebff914d74bb541558c2b6082b78edb.tar.gz opensim-SC-e36d23a85ebff914d74bb541558c2b6082b78edb.tar.bz2 opensim-SC-e36d23a85ebff914d74bb541558c2b6082b78edb.tar.xz |
sqlite source (unix build) added to libraries
Diffstat (limited to 'libraries/sqlite/unix/sqlite-3.5.1/www/lang.tcl')
-rw-r--r-- | libraries/sqlite/unix/sqlite-3.5.1/www/lang.tcl | 2203 |
1 files changed, 2203 insertions, 0 deletions
diff --git a/libraries/sqlite/unix/sqlite-3.5.1/www/lang.tcl b/libraries/sqlite/unix/sqlite-3.5.1/www/lang.tcl new file mode 100644 index 0000000..1c8b1e7 --- /dev/null +++ b/libraries/sqlite/unix/sqlite-3.5.1/www/lang.tcl | |||
@@ -0,0 +1,2203 @@ | |||
1 | # | ||
2 | # Run this Tcl script to generate the lang-*.html files. | ||
3 | # | ||
4 | set rcsid {$Id: lang.tcl,v 1.136 2007/10/03 20:15:28 drh Exp $} | ||
5 | source common.tcl | ||
6 | |||
7 | if {[llength $argv]>0} { | ||
8 | set outputdir [lindex $argv 0] | ||
9 | } else { | ||
10 | set outputdir "" | ||
11 | } | ||
12 | |||
13 | header {Query Language Understood by SQLite} | ||
14 | puts { | ||
15 | <h1 class="pdf_section">SQL As Understood By SQLite</h1> | ||
16 | |||
17 | <p>The SQLite library understands most of the standard SQL | ||
18 | language. But it does <a href="omitted.html">omit some features</a> | ||
19 | while at the same time | ||
20 | adding a few features of its own. This document attempts to | ||
21 | describe precisely what parts of the SQL language SQLite does | ||
22 | and does not support. A list of <a href="lang_keywords.html">keywords</a> is | ||
23 | also provided.</p> | ||
24 | |||
25 | <p>In all of the syntax diagrams that follow, literal text is shown in | ||
26 | bold blue. Non-terminal symbols are shown in italic red. Operators | ||
27 | that are part of the syntactic markup itself are shown in black roman.</p> | ||
28 | |||
29 | <p>This document is just an overview of the SQL syntax implemented | ||
30 | by SQLite. Many low-level productions are omitted. For detailed information | ||
31 | on the language that SQLite understands, refer to the source code and | ||
32 | the grammar file "parse.y".</p> | ||
33 | |||
34 | <div class="pdf_ignore"> | ||
35 | <p>SQLite implements the follow syntax:</p> | ||
36 | <p><ul> | ||
37 | } | ||
38 | |||
39 | proc slink {label} { | ||
40 | if {[string match *.html $label]} { | ||
41 | return $label | ||
42 | } | ||
43 | if {[string length $::outputdir]==0} { | ||
44 | return #$label | ||
45 | } else { | ||
46 | return lang_$label.html | ||
47 | } | ||
48 | } | ||
49 | |||
50 | foreach {section} [lsort -index 0 -dictionary { | ||
51 | {{CREATE TABLE} createtable} | ||
52 | {{CREATE VIRTUAL TABLE} createvtab} | ||
53 | {{CREATE INDEX} createindex} | ||
54 | {VACUUM vacuum} | ||
55 | {{DROP TABLE} droptable} | ||
56 | {{DROP INDEX} dropindex} | ||
57 | {INSERT insert} | ||
58 | {REPLACE replace} | ||
59 | {DELETE delete} | ||
60 | {UPDATE update} | ||
61 | {SELECT select} | ||
62 | {comment comment} | ||
63 | {COPY copy} | ||
64 | {EXPLAIN explain} | ||
65 | {expression expr} | ||
66 | {{BEGIN TRANSACTION} transaction} | ||
67 | {{COMMIT TRANSACTION} transaction} | ||
68 | {{END TRANSACTION} transaction} | ||
69 | {{ROLLBACK TRANSACTION} transaction} | ||
70 | {PRAGMA pragma.html} | ||
71 | {{ON CONFLICT clause} conflict} | ||
72 | {{CREATE VIEW} createview} | ||
73 | {{DROP VIEW} dropview} | ||
74 | {{CREATE TRIGGER} createtrigger} | ||
75 | {{DROP TRIGGER} droptrigger} | ||
76 | {{ATTACH DATABASE} attach} | ||
77 | {{DETACH DATABASE} detach} | ||
78 | {REINDEX reindex} | ||
79 | {{ALTER TABLE} altertable} | ||
80 | {{ANALYZE} analyze} | ||
81 | }] { | ||
82 | foreach {s_title s_tag} $section {} | ||
83 | puts "<li><a href=\"[slink $s_tag]\">$s_title</a></li>" | ||
84 | } | ||
85 | puts {</ul></p> | ||
86 | </div> | ||
87 | |||
88 | <p>Details on the implementation of each command are provided in | ||
89 | the sequel.</p> | ||
90 | } | ||
91 | |||
92 | proc Operator {name} { | ||
93 | return "<font color=\"#2c2cf0\"><big>$name</big></font>" | ||
94 | } | ||
95 | proc Nonterminal {name} { | ||
96 | return "<i><font color=\"#ff3434\">$name</font></i>" | ||
97 | } | ||
98 | proc Keyword {name} { | ||
99 | return "<font color=\"#2c2cf0\">$name</font>" | ||
100 | } | ||
101 | proc Example {text} { | ||
102 | puts "<blockquote><pre>$text</pre></blockquote>" | ||
103 | } | ||
104 | |||
105 | proc Section {name label} { | ||
106 | global outputdir | ||
107 | |||
108 | if {[string length $outputdir]!=0} { | ||
109 | if {[llength [info commands puts_standard]]>0} { | ||
110 | footer $::rcsid | ||
111 | } | ||
112 | |||
113 | if {[string length $label]>0} { | ||
114 | rename puts puts_standard | ||
115 | proc puts {str} { | ||
116 | regsub -all {href="#([a-z]+)"} $str {href="lang_\1.html"} str | ||
117 | puts_standard $::section_file $str | ||
118 | } | ||
119 | rename footer footer_standard | ||
120 | proc footer {id} { | ||
121 | footer_standard $id | ||
122 | rename footer "" | ||
123 | rename puts "" | ||
124 | rename puts_standard puts | ||
125 | rename footer_standard footer | ||
126 | } | ||
127 | set ::section_file [open [file join $outputdir lang_$label.html] w] | ||
128 | header "Query Language Understood by SQLite: $name" | ||
129 | puts "<h1>SQL As Understood By SQLite</h1>" | ||
130 | puts "<a href=\"lang.html\">\[Contents\]</a>" | ||
131 | puts "<h2>$name</h2>" | ||
132 | return | ||
133 | } | ||
134 | } | ||
135 | puts "\n<hr />" | ||
136 | if {$label!=""} { | ||
137 | puts "<a name=\"$label\"></a>" | ||
138 | } | ||
139 | puts "<h1>$name</h1>\n" | ||
140 | } | ||
141 | |||
142 | Section {ALTER TABLE} altertable | ||
143 | |||
144 | Syntax {sql-statement} { | ||
145 | ALTER TABLE [<database-name> .] <table-name> <alteration> | ||
146 | } {alteration} { | ||
147 | RENAME TO <new-table-name> | ||
148 | } {alteration} { | ||
149 | ADD [COLUMN] <column-def> | ||
150 | } | ||
151 | |||
152 | puts { | ||
153 | <p>SQLite's version of the ALTER TABLE command allows the user to | ||
154 | rename or add a new column to an existing table. It is not possible | ||
155 | to remove a column from a table. | ||
156 | </p> | ||
157 | |||
158 | <p>The RENAME TO syntax is used to rename the table identified by | ||
159 | <i>[database-name.]table-name</i> to <i>new-table-name</i>. This command | ||
160 | cannot be used to move a table between attached databases, only to rename | ||
161 | a table within the same database.</p> | ||
162 | |||
163 | <p>If the table being renamed has triggers or indices, then these remain | ||
164 | attached to the table after it has been renamed. However, if there are | ||
165 | any view definitions, or statements executed by triggers that refer to | ||
166 | the table being renamed, these are not automatically modified to use the new | ||
167 | table name. If this is required, the triggers or view definitions must be | ||
168 | dropped and recreated to use the new table name by hand. | ||
169 | </p> | ||
170 | |||
171 | <p>The ADD [COLUMN] syntax is used to add a new column to an existing table. | ||
172 | The new column is always appended to the end of the list of existing columns. | ||
173 | <i>Column-def</i> may take any of the forms permissable in a CREATE TABLE | ||
174 | statement, with the following restrictions: | ||
175 | <ul> | ||
176 | <li>The column may not have a PRIMARY KEY or UNIQUE constraint.</li> | ||
177 | <li>The column may not have a default value of CURRENT_TIME, CURRENT_DATE | ||
178 | or CURRENT_TIMESTAMP.</li> | ||
179 | <li>If a NOT NULL constraint is specified, then the column must have a | ||
180 | default value other than NULL. | ||
181 | </ul> | ||
182 | |||
183 | <p>The execution time of the ALTER TABLE command is independent of | ||
184 | the amount of data in the table. The ALTER TABLE command runs as quickly | ||
185 | on a table with 10 million rows as it does on a table with 1 row. | ||
186 | </p> | ||
187 | |||
188 | <p>After ADD COLUMN has been run on a database, that database will not | ||
189 | be readable by SQLite version 3.1.3 and earlier until the database | ||
190 | is <a href="lang_vacuum.html">VACUUM</a>ed.</p> | ||
191 | } | ||
192 | |||
193 | Section {ANALYZE} analyze | ||
194 | |||
195 | Syntax {sql-statement} { | ||
196 | ANALYZE | ||
197 | } | ||
198 | Syntax {sql-statement} { | ||
199 | ANALYZE <database-name> | ||
200 | } | ||
201 | Syntax {sql-statement} { | ||
202 | ANALYZE [<database-name> .] <table-name> | ||
203 | } | ||
204 | |||
205 | puts { | ||
206 | <p>The ANALYZE command gathers statistics about indices and stores them | ||
207 | in a special tables in the database where the query optimizer can use | ||
208 | them to help make better index choices. | ||
209 | If no arguments are given, all indices in all attached databases are | ||
210 | analyzed. If a database name is given as the argument, all indices | ||
211 | in that one database are analyzed. If the argument is a table name, | ||
212 | then only indices associated with that one table are analyzed.</p> | ||
213 | |||
214 | <p>The initial implementation stores all statistics in a single | ||
215 | table named <b>sqlite_stat1</b>. Future enhancements may create | ||
216 | additional tables with the same name pattern except with the "1" | ||
217 | changed to a different digit. The <b>sqlite_stat1</b> table cannot | ||
218 | be <a href="#droptable">DROP</a>ped, | ||
219 | but all the content can be <a href="#delete">DELETE</a>d which has the | ||
220 | same effect.</p> | ||
221 | } | ||
222 | |||
223 | Section {ATTACH DATABASE} attach | ||
224 | |||
225 | Syntax {sql-statement} { | ||
226 | ATTACH [DATABASE] <database-filename> AS <database-name> | ||
227 | } | ||
228 | |||
229 | puts { | ||
230 | <p>The ATTACH DATABASE statement adds another database | ||
231 | file to the current database connection. If the filename contains | ||
232 | punctuation characters it must be quoted. The names 'main' and | ||
233 | 'temp' refer to the main database and the database used for | ||
234 | temporary tables. These cannot be detached. Attached databases | ||
235 | are removed using the <a href="#detach">DETACH DATABASE</a> | ||
236 | statement.</p> | ||
237 | |||
238 | <p>You can read from and write to an attached database and you | ||
239 | can modify the schema of the attached database. This is a new | ||
240 | feature of SQLite version 3.0. In SQLite 2.8, schema changes | ||
241 | to attached databases were not allowed.</p> | ||
242 | |||
243 | <p>You cannot create a new table with the same name as a table in | ||
244 | an attached database, but you can attach a database which contains | ||
245 | tables whose names are duplicates of tables in the main database. It is | ||
246 | also permissible to attach the same database file multiple times.</p> | ||
247 | |||
248 | <p>Tables in an attached database can be referred to using the syntax | ||
249 | <i>database-name.table-name</i>. If an attached table doesn't have | ||
250 | a duplicate table name in the main database, it doesn't require a | ||
251 | database name prefix. When a database is attached, all of its | ||
252 | tables which don't have duplicate names become the default table | ||
253 | of that name. Any tables of that name attached afterwards require the table | ||
254 | prefix. If the default table of a given name is detached, then | ||
255 | the last table of that name attached becomes the new default.</p> | ||
256 | |||
257 | <p> | ||
258 | Transactions involving multiple attached databases are atomic, | ||
259 | assuming that the main database is not ":memory:". If the main | ||
260 | database is ":memory:" then | ||
261 | transactions continue to be atomic within each individual | ||
262 | database file. But if the host computer crashes in the middle | ||
263 | of a COMMIT where two or more database files are updated, | ||
264 | some of those files might get the changes where others | ||
265 | might not. | ||
266 | Atomic commit of attached databases is a new feature of SQLite version 3.0. | ||
267 | In SQLite version 2.8, all commits to attached databases behaved as if | ||
268 | the main database were ":memory:". | ||
269 | </p> | ||
270 | |||
271 | <p>There is a compile-time limit of 10 attached database files.</p> | ||
272 | } | ||
273 | |||
274 | |||
275 | Section {BEGIN TRANSACTION} transaction | ||
276 | |||
277 | Syntax {sql-statement} { | ||
278 | BEGIN [ DEFERRED | IMMEDIATE | EXCLUSIVE ] [TRANSACTION [<name>]] | ||
279 | } | ||
280 | Syntax {sql-statement} { | ||
281 | END [TRANSACTION [<name>]] | ||
282 | } | ||
283 | Syntax {sql-statement} { | ||
284 | COMMIT [TRANSACTION [<name>]] | ||
285 | } | ||
286 | Syntax {sql-statement} { | ||
287 | ROLLBACK [TRANSACTION [<name>]] | ||
288 | } | ||
289 | |||
290 | puts { | ||
291 | |||
292 | <p> | ||
293 | No changes can be made to the database except within a transaction. | ||
294 | Any command that changes the database (basically, any SQL command | ||
295 | other than SELECT) will automatically start a transaction if | ||
296 | one is not already in effect. Automatically started transactions | ||
297 | are committed at the conclusion of the command. | ||
298 | </p> | ||
299 | |||
300 | <p> | ||
301 | Transactions can be started manually using the BEGIN | ||
302 | command. Such transactions usually persist until the next | ||
303 | COMMIT or ROLLBACK command. But a transaction will also | ||
304 | ROLLBACK if the database is closed or if an error occurs | ||
305 | and the ROLLBACK conflict resolution algorithm is specified. | ||
306 | See the documentation on the <a href="#conflict">ON CONFLICT</a> | ||
307 | clause for additional information about the ROLLBACK | ||
308 | conflict resolution algorithm. | ||
309 | </p> | ||
310 | |||
311 | <p> | ||
312 | END TRANSACTION is an alias for COMMIT. | ||
313 | </p> | ||
314 | |||
315 | <p>The optional transaction name is current ignored. SQLite | ||
316 | does not recognize nested transactions at this time. | ||
317 | However, future versions of SQLite may be enhanced to support nested | ||
318 | transactions and the transaction name would then become significant. | ||
319 | Application are advised not to use the transaction name in order | ||
320 | to avoid future compatibility problems.</p> | ||
321 | |||
322 | <p> | ||
323 | Transactions can be deferred, immediate, or exclusive. | ||
324 | The default transaction behavior is deferred. | ||
325 | Deferred means that no locks are acquired | ||
326 | on the database until the database is first accessed. Thus with a | ||
327 | deferred transaction, the BEGIN statement itself does nothing. Locks | ||
328 | are not acquired until the first read or write operation. The first read | ||
329 | operation against a database creates a SHARED lock and the first | ||
330 | write operation creates a RESERVED lock. Because the acquisition of | ||
331 | locks is deferred until they are needed, it is possible that another | ||
332 | thread or process could create a separate transaction and write to | ||
333 | the database after the BEGIN on the current thread has executed. | ||
334 | If the transaction is immediate, then RESERVED locks | ||
335 | are acquired on all databases as soon as the BEGIN command is | ||
336 | executed, without waiting for the | ||
337 | database to be used. After a BEGIN IMMEDIATE, you are guaranteed that | ||
338 | no other thread or process will be able to write to the database or | ||
339 | do a BEGIN IMMEDIATE or BEGIN EXCLUSIVE. Other processes can continue | ||
340 | to read from the database, however. An exclusive transaction causes | ||
341 | EXCLUSIVE locks to be acquired on all databases. After a BEGIN | ||
342 | EXCLUSIVE, you are guaranteed that no other thread or process will | ||
343 | be able to read or write the database until the transaction is | ||
344 | complete. | ||
345 | </p> | ||
346 | |||
347 | <p> | ||
348 | A description of the meaning of SHARED, RESERVED, and EXCLUSIVE locks | ||
349 | is available <a href="lockingv3.html">separately</a>. | ||
350 | </p> | ||
351 | |||
352 | <p> | ||
353 | The COMMIT command does not actually perform a commit until all | ||
354 | pending SQL commands finish. Thus if two or more SELECT statements | ||
355 | are in the middle of processing and a COMMIT is executed, the commit | ||
356 | will not actually occur until all SELECT statements finish. | ||
357 | </p> | ||
358 | |||
359 | <p> | ||
360 | An attempt to execute COMMIT might result in an SQLITE_BUSY return code. | ||
361 | This indicates that another thread or process had a read lock on the database | ||
362 | that prevented the database from being updated. When COMMIT fails in this | ||
363 | way, the transaction remains active and the COMMIT can be retried later | ||
364 | after the reader has had a chance to clear. | ||
365 | </p> | ||
366 | |||
367 | <h3>Response To Errors Within A Transaction</h3> | ||
368 | |||
369 | <p>If certain kinds of errors occur within a transaction, the | ||
370 | transaction may or may not be rolled back automatically. The | ||
371 | errors that cause the behavior include:</p> | ||
372 | |||
373 | <ul> | ||
374 | <li> SQLITE_FULL: database or disk full | ||
375 | <li> SQLITE_IOERR: disk I/O error | ||
376 | <li> SQLITE_BUSY: database in use by another process | ||
377 | <li> SQLITE_NOMEM: out or memory | ||
378 | <li> SQLITE_INTERRUPT: processing interrupted by user request | ||
379 | </ul> | ||
380 | |||
381 | <p> | ||
382 | For all of these errors, SQLite attempts to undo just the one statement | ||
383 | it was working on and leave changes from prior statements within the | ||
384 | same transaction intact and continue with the transaction. However, | ||
385 | depending on the statement being evaluated and the point at which the | ||
386 | error occurs, it might be necessary for SQLite to rollback and | ||
387 | cancel the transaction. An application can tell which | ||
388 | course of action SQLite took by using the | ||
389 | <a href="capi3ref.html#sqlite3_get_autocommit">sqlite3_get_autocommit()</a> | ||
390 | C-language interface.</p> | ||
391 | |||
392 | <p>It is recommended that applications respond to the errors | ||
393 | listed above by explicitly issuing a ROLLBACK command. If the | ||
394 | transaction has already been rolled back automatically | ||
395 | by the error response, then the ROLLBACK command will fail with an | ||
396 | error, but no harm is caused by this.</p> | ||
397 | |||
398 | <p>Future versions of SQLite may extend the list of errors which | ||
399 | might cause automatic transaction rollback. Future versions of | ||
400 | SQLite might change the error response. In particular, we may | ||
401 | choose to simplify the interface in future versions of SQLite by | ||
402 | causing the errors above to force an unconditional rollback.</p> | ||
403 | } | ||
404 | |||
405 | |||
406 | Section comment comment | ||
407 | |||
408 | Syntax {comment} {<SQL-comment> | <C-comment> | ||
409 | } {SQL-comment} {-- <single-line> | ||
410 | } {C-comment} {/STAR <multiple-lines> [STAR/] | ||
411 | } | ||
412 | |||
413 | puts { | ||
414 | <p> Comments aren't SQL commands, but can occur in SQL queries. They are | ||
415 | treated as whitespace by the parser. They can begin anywhere whitespace | ||
416 | can be found, including inside expressions that span multiple lines. | ||
417 | </p> | ||
418 | |||
419 | <p> SQL comments only extend to the end of the current line.</p> | ||
420 | |||
421 | <p> C comments can span any number of lines. If there is no terminating | ||
422 | delimiter, they extend to the end of the input. This is not treated as | ||
423 | an error. A new SQL statement can begin on a line after a multiline | ||
424 | comment ends. C comments can be embedded anywhere whitespace can occur, | ||
425 | including inside expressions, and in the middle of other SQL statements. | ||
426 | C comments do not nest. SQL comments inside a C comment will be ignored. | ||
427 | </p> | ||
428 | } | ||
429 | |||
430 | |||
431 | Section COPY copy | ||
432 | |||
433 | Syntax {sql-statement} { | ||
434 | COPY [ OR <conflict-algorithm> ] [<database-name> .] <table-name> FROM <filename> | ||
435 | [ USING DELIMITERS <delim> ] | ||
436 | } | ||
437 | |||
438 | puts { | ||
439 | <p>The COPY command is available in SQLite version 2.8 and earlier. | ||
440 | The COPY command has been removed from SQLite version 3.0 due to | ||
441 | complications in trying to support it in a mixed UTF-8/16 environment. | ||
442 | In version 3.0, the <a href="sqlite.html">command-line shell</a> | ||
443 | contains a new command <b>.import</b> that can be used as a substitute | ||
444 | for COPY. | ||
445 | </p> | ||
446 | |||
447 | <p>The COPY command is an extension used to load large amounts of | ||
448 | data into a table. It is modeled after a similar command found | ||
449 | in PostgreSQL. In fact, the SQLite COPY command is specifically | ||
450 | designed to be able to read the output of the PostgreSQL dump | ||
451 | utility <b>pg_dump</b> so that data can be easily transferred from | ||
452 | PostgreSQL into SQLite.</p> | ||
453 | |||
454 | <p>The table-name is the name of an existing table which is to | ||
455 | be filled with data. The filename is a string or identifier that | ||
456 | names a file from which data will be read. The filename can be | ||
457 | the <b>STDIN</b> to read data from standard input.</p> | ||
458 | |||
459 | <p>Each line of the input file is converted into a single record | ||
460 | in the table. Columns are separated by tabs. If a tab occurs as | ||
461 | data within a column, then that tab is preceded by a baskslash "\" | ||
462 | character. A baskslash in the data appears as two backslashes in | ||
463 | a row. The optional USING DELIMITERS clause can specify a delimiter | ||
464 | other than tab.</p> | ||
465 | |||
466 | <p>If a column consists of the character "\N", that column is filled | ||
467 | with the value NULL.</p> | ||
468 | |||
469 | <p>The optional conflict-clause allows the specification of an alternative | ||
470 | constraint conflict resolution algorithm to use for this one command. | ||
471 | See the section titled | ||
472 | <a href="#conflict">ON CONFLICT</a> for additional information.</p> | ||
473 | |||
474 | <p>When the input data source is STDIN, the input can be terminated | ||
475 | by a line that contains only a baskslash and a dot:} | ||
476 | puts "\"[Operator \\.]\".</p>" | ||
477 | |||
478 | |||
479 | Section {CREATE INDEX} createindex | ||
480 | |||
481 | Syntax {sql-statement} { | ||
482 | CREATE [UNIQUE] INDEX [IF NOT EXISTS] [<database-name> .] <index-name> | ||
483 | ON <table-name> ( <column-name> [, <column-name>]* ) | ||
484 | } {column-name} { | ||
485 | <name> [ COLLATE <collation-name>] [ ASC | DESC ] | ||
486 | } | ||
487 | |||
488 | puts { | ||
489 | <p>The CREATE INDEX command consists of the keywords "CREATE INDEX" followed | ||
490 | by the name of the new index, the keyword "ON", the name of a previously | ||
491 | created table that is to be indexed, and a parenthesized list of names of | ||
492 | columns in the table that are used for the index key. | ||
493 | Each column name can be followed by one of the "ASC" or "DESC" keywords | ||
494 | to indicate sort order, but the sort order is ignored in the current | ||
495 | implementation. Sorting is always done in ascending order.</p> | ||
496 | |||
497 | <p>The COLLATE clause following each column name defines a collating | ||
498 | sequence used for text entires in that column. The default collating | ||
499 | sequence is the collating sequence defined for that column in the | ||
500 | CREATE TABLE statement. Or if no collating sequence is otherwise defined, | ||
501 | the built-in BINARY collating sequence is used.</p> | ||
502 | |||
503 | <p>There are no arbitrary limits on the number of indices that can be | ||
504 | attached to a single table, nor on the number of columns in an index.</p> | ||
505 | |||
506 | <p>If the UNIQUE keyword appears between CREATE and INDEX then duplicate | ||
507 | index entries are not allowed. Any attempt to insert a duplicate entry | ||
508 | will result in an error.</p> | ||
509 | |||
510 | <p>The exact text | ||
511 | of each CREATE INDEX statement is stored in the <b>sqlite_master</b> | ||
512 | or <b>sqlite_temp_master</b> table, depending on whether the table | ||
513 | being indexed is temporary. Every time the database is opened, | ||
514 | all CREATE INDEX statements | ||
515 | are read from the <b>sqlite_master</b> table and used to regenerate | ||
516 | SQLite's internal representation of the index layout.</p> | ||
517 | |||
518 | <p>If the optional IF NOT EXISTS clause is present and another index | ||
519 | with the same name aleady exists, then this command becomes a no-op.</p> | ||
520 | |||
521 | <p>Indexes are removed with the <a href="#dropindex">DROP INDEX</a> | ||
522 | command.</p> | ||
523 | } | ||
524 | |||
525 | |||
526 | Section {CREATE TABLE} {createtable} | ||
527 | |||
528 | Syntax {sql-command} { | ||
529 | CREATE [TEMP | TEMPORARY] TABLE [IF NOT EXISTS] [<database-name> .] <table-name> ( | ||
530 | <column-def> [, <column-def>]* | ||
531 | [, <constraint>]* | ||
532 | ) | ||
533 | } {sql-command} { | ||
534 | CREATE [TEMP | TEMPORARY] TABLE [<database-name>.] <table-name> AS <select-statement> | ||
535 | } {column-def} { | ||
536 | <name> [<type>] [[CONSTRAINT <name>] <column-constraint>]* | ||
537 | } {type} { | ||
538 | <typename> | | ||
539 | <typename> ( <number> ) | | ||
540 | <typename> ( <number> , <number> ) | ||
541 | } {column-constraint} { | ||
542 | NOT NULL [ <conflict-clause> ] | | ||
543 | PRIMARY KEY [<sort-order>] [ <conflict-clause> ] [AUTOINCREMENT] | | ||
544 | UNIQUE [ <conflict-clause> ] | | ||
545 | CHECK ( <expr> ) | | ||
546 | DEFAULT <value> | | ||
547 | COLLATE <collation-name> | ||
548 | } {constraint} { | ||
549 | PRIMARY KEY ( <column-list> ) [ <conflict-clause> ] | | ||
550 | UNIQUE ( <column-list> ) [ <conflict-clause> ] | | ||
551 | CHECK ( <expr> ) | ||
552 | } {conflict-clause} { | ||
553 | ON CONFLICT <conflict-algorithm> | ||
554 | } | ||
555 | |||
556 | puts { | ||
557 | <p>A CREATE TABLE statement is basically the keywords "CREATE TABLE" | ||
558 | followed by the name of a new table and a parenthesized list of column | ||
559 | definitions and constraints. The table name can be either an identifier | ||
560 | or a string. Tables names that begin with "<b>sqlite_</b>" are reserved | ||
561 | for use by the engine.</p> | ||
562 | |||
563 | <p>Each column definition is the name of the column followed by the | ||
564 | datatype for that column, then one or more optional column constraints. | ||
565 | The datatype for the column does not restrict what data may be put | ||
566 | in that column. | ||
567 | See <a href="datatype3.html">Datatypes In SQLite Version 3</a> for | ||
568 | additional information. | ||
569 | The UNIQUE constraint causes an index to be created on the specified | ||
570 | columns. This index must contain unique keys. | ||
571 | The COLLATE clause specifies what text <a href="datatype3.html#collation"> | ||
572 | collating function</a> to use when comparing text entries for the column. | ||
573 | The built-in BINARY collating function is used by default. | ||
574 | <p> | ||
575 | The DEFAULT constraint specifies a default value to use when doing an INSERT. | ||
576 | The value may be NULL, a string constant or a number. Starting with version | ||
577 | 3.1.0, the default value may also be one of the special case-independant | ||
578 | keywords CURRENT_TIME, CURRENT_DATE or CURRENT_TIMESTAMP. If the value is | ||
579 | NULL, a string constant or number, it is literally inserted into the column | ||
580 | whenever an INSERT statement that does not specify a value for the column is | ||
581 | executed. If the value is CURRENT_TIME, CURRENT_DATE or CURRENT_TIMESTAMP, then | ||
582 | the current UTC date and/or time is inserted into the columns. For | ||
583 | CURRENT_TIME, the format is HH:MM:SS. For CURRENT_DATE, YYYY-MM-DD. The format | ||
584 | for CURRENT_TIMESTAMP is "YYYY-MM-DD HH:MM:SS". | ||
585 | </p> | ||
586 | |||
587 | <p>Specifying a PRIMARY KEY normally just creates a UNIQUE index | ||
588 | on the corresponding columns. However, if primary key is on a single column | ||
589 | that has datatype INTEGER, then that column is used internally | ||
590 | as the actual key of the B-Tree for the table. This means that the column | ||
591 | may only hold unique integer values. (Except for this one case, | ||
592 | SQLite ignores the datatype specification of columns and allows | ||
593 | any kind of data to be put in a column regardless of its declared | ||
594 | datatype.) If a table does not have an INTEGER PRIMARY KEY column, | ||
595 | then the B-Tree key will be a automatically generated integer. | ||
596 | <a name="rowid"> The | ||
597 | B-Tree key for a row can always be accessed using one of the | ||
598 | special names "<b>ROWID</b>", "<b>OID</b>", or "<b>_ROWID_</b>". | ||
599 | This is true regardless of whether or not there is an INTEGER | ||
600 | PRIMARY KEY. An INTEGER PRIMARY KEY column can also include the | ||
601 | keyword AUTOINCREMENT. The AUTOINCREMENT keyword modified the way | ||
602 | that B-Tree keys are automatically generated. Additional detail | ||
603 | on automatic B-Tree key generation is available | ||
604 | <a href="autoinc.html">separately</a>.</p> | ||
605 | |||
606 | <p>According to the SQL standard, PRIMARY KEY should imply NOT NULL. | ||
607 | Unfortunately, due to a long-standing coding oversight, this is not | ||
608 | the case in SQLite. SQLite allows NULL values | ||
609 | in a PRIMARY KEY column. We could change SQLite to conform to the | ||
610 | standard (and we might do so in the future), but by the time the | ||
611 | oversight was discovered, SQLite was in such wide use that we feared | ||
612 | breaking legacy code if we fixed the problem. So for now we have | ||
613 | chosen to contain allowing NULLs in PRIMARY KEY columns. | ||
614 | Developers should be aware, however, that we may change SQLite to | ||
615 | conform to the SQL standard in future and should design new programs | ||
616 | accordingly.</p> | ||
617 | |||
618 | <p>If the "TEMP" or "TEMPORARY" keyword occurs in between "CREATE" | ||
619 | and "TABLE" then the table that is created is only visible | ||
620 | within that same database connection | ||
621 | and is automatically deleted when | ||
622 | the database connection is closed. Any indices created on a temporary table | ||
623 | are also temporary. Temporary tables and indices are stored in a | ||
624 | separate file distinct from the main database file.</p> | ||
625 | |||
626 | <p> If a <database-name> is specified, then the table is created in | ||
627 | the named database. It is an error to specify both a <database-name> | ||
628 | and the TEMP keyword, unless the <database-name> is "temp". If no | ||
629 | database name is specified, and the TEMP keyword is not present, | ||
630 | the table is created in the main database.</p> | ||
631 | |||
632 | <p>The optional conflict-clause following each constraint | ||
633 | allows the specification of an alternative default | ||
634 | constraint conflict resolution algorithm for that constraint. | ||
635 | The default is abort ABORT. Different constraints within the same | ||
636 | table may have different default conflict resolution algorithms. | ||
637 | If an COPY, INSERT, or UPDATE command specifies a different conflict | ||
638 | resolution algorithm, then that algorithm is used in place of the | ||
639 | default algorithm specified in the CREATE TABLE statement. | ||
640 | See the section titled | ||
641 | <a href="#conflict">ON CONFLICT</a> for additional information.</p> | ||
642 | |||
643 | <p>CHECK constraints are supported as of version 3.3.0. Prior | ||
644 | to version 3.3.0, CHECK constraints were parsed but not enforced.</p> | ||
645 | |||
646 | <p>There are no arbitrary limits on the number | ||
647 | of columns or on the number of constraints in a table. | ||
648 | The total amount of data in a single row is limited to about | ||
649 | 1 megabytes in version 2.8. In version 3.0 there is no arbitrary | ||
650 | limit on the amount of data in a row.</p> | ||
651 | |||
652 | |||
653 | <p>The CREATE TABLE AS form defines the table to be | ||
654 | the result set of a query. The names of the table columns are | ||
655 | the names of the columns in the result.</p> | ||
656 | |||
657 | <p>The exact text | ||
658 | of each CREATE TABLE statement is stored in the <b>sqlite_master</b> | ||
659 | table. Every time the database is opened, all CREATE TABLE statements | ||
660 | are read from the <b>sqlite_master</b> table and used to regenerate | ||
661 | SQLite's internal representation of the table layout. | ||
662 | If the original command was a CREATE TABLE AS then then an equivalent | ||
663 | CREATE TABLE statement is synthesized and store in <b>sqlite_master</b> | ||
664 | in place of the original command. | ||
665 | The text of CREATE TEMPORARY TABLE statements are stored in the | ||
666 | <b>sqlite_temp_master</b> table. | ||
667 | </p> | ||
668 | |||
669 | <p>If the optional IF NOT EXISTS clause is present and another table | ||
670 | with the same name aleady exists, then this command becomes a no-op.</p> | ||
671 | |||
672 | <p>Tables are removed using the <a href="#droptable">DROP TABLE</a> | ||
673 | statement. </p> | ||
674 | } | ||
675 | |||
676 | |||
677 | Section {CREATE TRIGGER} createtrigger | ||
678 | |||
679 | Syntax {sql-statement} { | ||
680 | CREATE [TEMP | TEMPORARY] TRIGGER [IF NOT EXISTS] <trigger-name> [ BEFORE | AFTER ] | ||
681 | <database-event> ON [<database-name> .] <table-name> | ||
682 | <trigger-action> | ||
683 | } | ||
684 | |||
685 | Syntax {sql-statement} { | ||
686 | CREATE [TEMP | TEMPORARY] TRIGGER [IF NOT EXISTS] <trigger-name> INSTEAD OF | ||
687 | <database-event> ON [<database-name> .] <view-name> | ||
688 | <trigger-action> | ||
689 | } | ||
690 | |||
691 | Syntax {database-event} { | ||
692 | DELETE | | ||
693 | INSERT | | ||
694 | UPDATE | | ||
695 | UPDATE OF <column-list> | ||
696 | } | ||
697 | |||
698 | Syntax {trigger-action} { | ||
699 | [ FOR EACH ROW ] [ WHEN <expression> ] | ||
700 | BEGIN | ||
701 | <trigger-step> ; [ <trigger-step> ; ]* | ||
702 | END | ||
703 | } | ||
704 | |||
705 | Syntax {trigger-step} { | ||
706 | <update-statement> | <insert-statement> | | ||
707 | <delete-statement> | <select-statement> | ||
708 | } | ||
709 | |||
710 | puts { | ||
711 | <p>The CREATE TRIGGER statement is used to add triggers to the | ||
712 | database schema. Triggers are database operations (the <i>trigger-action</i>) | ||
713 | that are automatically performed when a specified database event (the | ||
714 | <i>database-event</i>) occurs. </p> | ||
715 | |||
716 | <p>A trigger may be specified to fire whenever a DELETE, INSERT or UPDATE of a | ||
717 | particular database table occurs, or whenever an UPDATE of one or more | ||
718 | specified columns of a table are updated.</p> | ||
719 | |||
720 | <p>At this time SQLite supports only FOR EACH ROW triggers, not FOR EACH | ||
721 | STATEMENT triggers. Hence explicitly specifying FOR EACH ROW is optional. FOR | ||
722 | EACH ROW implies that the SQL statements specified as <i>trigger-steps</i> | ||
723 | may be executed (depending on the WHEN clause) for each database row being | ||
724 | inserted, updated or deleted by the statement causing the trigger to fire.</p> | ||
725 | |||
726 | <p>Both the WHEN clause and the <i>trigger-steps</i> may access elements of | ||
727 | the row being inserted, deleted or updated using references of the form | ||
728 | "NEW.<i>column-name</i>" and "OLD.<i>column-name</i>", where | ||
729 | <i>column-name</i> is the name of a column from the table that the trigger | ||
730 | is associated with. OLD and NEW references may only be used in triggers on | ||
731 | <i>trigger-event</i>s for which they are relevant, as follows:</p> | ||
732 | |||
733 | <table border=0 cellpadding=10> | ||
734 | <tr> | ||
735 | <td valign="top" align="right" width=120><i>INSERT</i></td> | ||
736 | <td valign="top">NEW references are valid</td> | ||
737 | </tr> | ||
738 | <tr> | ||
739 | <td valign="top" align="right" width=120><i>UPDATE</i></td> | ||
740 | <td valign="top">NEW and OLD references are valid</td> | ||
741 | </tr> | ||
742 | <tr> | ||
743 | <td valign="top" align="right" width=120><i>DELETE</i></td> | ||
744 | <td valign="top">OLD references are valid</td> | ||
745 | </tr> | ||
746 | </table> | ||
747 | </p> | ||
748 | |||
749 | <p>If a WHEN clause is supplied, the SQL statements specified as <i>trigger-steps</i> are only executed for rows for which the WHEN clause is true. If no WHEN clause is supplied, the SQL statements are executed for all rows.</p> | ||
750 | |||
751 | <p>The specified <i>trigger-time</i> determines when the <i>trigger-steps</i> | ||
752 | will be executed relative to the insertion, modification or removal of the | ||
753 | associated row.</p> | ||
754 | |||
755 | <p>An ON CONFLICT clause may be specified as part of an UPDATE or INSERT | ||
756 | <i>trigger-step</i>. However if an ON CONFLICT clause is specified as part of | ||
757 | the statement causing the trigger to fire, then this conflict handling | ||
758 | policy is used instead.</p> | ||
759 | |||
760 | <p>Triggers are automatically dropped when the table that they are | ||
761 | associated with is dropped.</p> | ||
762 | |||
763 | <p>Triggers may be created on views, as well as ordinary tables, by specifying | ||
764 | INSTEAD OF in the CREATE TRIGGER statement. If one or more ON INSERT, ON DELETE | ||
765 | or ON UPDATE triggers are defined on a view, then it is not an error to execute | ||
766 | an INSERT, DELETE or UPDATE statement on the view, respectively. Thereafter, | ||
767 | executing an INSERT, DELETE or UPDATE on the view causes the associated | ||
768 | triggers to fire. The real tables underlying the view are not modified | ||
769 | (except possibly explicitly, by a trigger program).</p> | ||
770 | |||
771 | <p><b>Example:</b></p> | ||
772 | |||
773 | <p>Assuming that customer records are stored in the "customers" table, and | ||
774 | that order records are stored in the "orders" table, the following trigger | ||
775 | ensures that all associated orders are redirected when a customer changes | ||
776 | his or her address:</p> | ||
777 | } | ||
778 | Example { | ||
779 | CREATE TRIGGER update_customer_address UPDATE OF address ON customers | ||
780 | BEGIN | ||
781 | UPDATE orders SET address = new.address WHERE customer_name = old.name; | ||
782 | END; | ||
783 | } | ||
784 | puts { | ||
785 | <p>With this trigger installed, executing the statement:</p> | ||
786 | } | ||
787 | |||
788 | Example { | ||
789 | UPDATE customers SET address = '1 Main St.' WHERE name = 'Jack Jones'; | ||
790 | } | ||
791 | puts { | ||
792 | <p>causes the following to be automatically executed:</p> | ||
793 | } | ||
794 | Example { | ||
795 | UPDATE orders SET address = '1 Main St.' WHERE customer_name = 'Jack Jones'; | ||
796 | } | ||
797 | |||
798 | puts { | ||
799 | <p>Note that currently, triggers may behave oddly when created on tables | ||
800 | with INTEGER PRIMARY KEY fields. If a BEFORE trigger program modifies the | ||
801 | INTEGER PRIMARY KEY field of a row that will be subsequently updated by the | ||
802 | statement that causes the trigger to fire, then the update may not occur. | ||
803 | The workaround is to declare the table with a PRIMARY KEY column instead | ||
804 | of an INTEGER PRIMARY KEY column.</p> | ||
805 | } | ||
806 | |||
807 | puts { | ||
808 | <p>A special SQL function RAISE() may be used within a trigger-program, with the following syntax</p> | ||
809 | } | ||
810 | Syntax {raise-function} { | ||
811 | RAISE ( ABORT, <error-message> ) | | ||
812 | RAISE ( FAIL, <error-message> ) | | ||
813 | RAISE ( ROLLBACK, <error-message> ) | | ||
814 | RAISE ( IGNORE ) | ||
815 | } | ||
816 | puts { | ||
817 | <p>When one of the first three forms is called during trigger-program execution, the specified ON CONFLICT processing is performed (either ABORT, FAIL or | ||
818 | ROLLBACK) and the current query terminates. An error code of SQLITE_CONSTRAINT is returned to the user, along with the specified error message.</p> | ||
819 | |||
820 | <p>When RAISE(IGNORE) is called, the remainder of the current trigger program, | ||
821 | the statement that caused the trigger program to execute and any subsequent | ||
822 | trigger programs that would of been executed are abandoned. No database | ||
823 | changes are rolled back. If the statement that caused the trigger program | ||
824 | to execute is itself part of a trigger program, then that trigger program | ||
825 | resumes execution at the beginning of the next step. | ||
826 | </p> | ||
827 | |||
828 | <p>Triggers are removed using the <a href="#droptrigger">DROP TRIGGER</a> | ||
829 | statement.</p> | ||
830 | } | ||
831 | |||
832 | |||
833 | Section {CREATE VIEW} {createview} | ||
834 | |||
835 | Syntax {sql-command} { | ||
836 | CREATE [TEMP | TEMPORARY] VIEW [IF NOT EXISTS] [<database-name>.] <view-name> AS <select-statement> | ||
837 | } | ||
838 | |||
839 | puts { | ||
840 | <p>The CREATE VIEW command assigns a name to a pre-packaged | ||
841 | <a href="#select">SELECT</a> | ||
842 | statement. Once the view is created, it can be used in the FROM clause | ||
843 | of another SELECT in place of a table name. | ||
844 | </p> | ||
845 | |||
846 | <p>If the "TEMP" or "TEMPORARY" keyword occurs in between "CREATE" | ||
847 | and "VIEW" then the view that is created is only visible to the | ||
848 | process that opened the database and is automatically deleted when | ||
849 | the database is closed.</p> | ||
850 | |||
851 | <p> If a <database-name> is specified, then the view is created in | ||
852 | the named database. It is an error to specify both a <database-name> | ||
853 | and the TEMP keyword, unless the <database-name> is "temp". If no | ||
854 | database name is specified, and the TEMP keyword is not present, | ||
855 | the table is created in the main database.</p> | ||
856 | |||
857 | <p>You cannot COPY, DELETE, INSERT or UPDATE a view. Views are read-only | ||
858 | in SQLite. However, in many cases you can use a <a href="#createtrigger"> | ||
859 | TRIGGER</a> on the view to accomplish the same thing. Views are removed | ||
860 | with the <a href="#dropview">DROP VIEW</a> | ||
861 | command.</p> | ||
862 | } | ||
863 | |||
864 | Section {CREATE VIRTUAL TABLE} {createvtab} | ||
865 | |||
866 | Syntax {sql-command} { | ||
867 | CREATE VIRTUAL TABLE [<database-name> .] <table-name> USING <module-name> [( <arguments> )] | ||
868 | } | ||
869 | |||
870 | puts { | ||
871 | <p>A virtual table is an interface to an external storage or computation | ||
872 | engine that appears to be a table but does not actually store information | ||
873 | in the database file.</p> | ||
874 | |||
875 | <p>In general, you can do anything with a virtual table that can be done | ||
876 | with an ordinary table, except that you cannot create triggers on a | ||
877 | virtual table. Some virtual table implementations might impose additional | ||
878 | restrictions. For example, many virtual tables are read-only.</p> | ||
879 | |||
880 | <p>The <module-name> is the name of an object that implements | ||
881 | the virtual table. The <module-name> must be registered with | ||
882 | the SQLite database connection using | ||
883 | <a href="capi3ref.html#sqlite3_create_module">sqlite3_create_module</a> | ||
884 | prior to issuing the CREATE VIRTUAL TABLE statement. | ||
885 | The module takes zero or more comma-separated arguments. | ||
886 | The arguments can be just about any text as long as it has balanced | ||
887 | parentheses. The argument syntax is sufficiently general that the | ||
888 | arguments can be made to appear as column definitions in a traditional | ||
889 | <a href="#createtable">CREATE TABLE</a> statement. | ||
890 | SQLite passes the module arguments directly | ||
891 | to the module without any interpretation. It is the responsibility | ||
892 | of the module implementation to parse and interpret its own arguments.</p> | ||
893 | |||
894 | <p>A virtual table is destroyed using the ordinary | ||
895 | <a href="#droptable">DROP TABLE</a> statement. There is no | ||
896 | DROP VIRTUAL TABLE statement.</p> | ||
897 | } | ||
898 | |||
899 | Section DELETE delete | ||
900 | |||
901 | Syntax {sql-statement} { | ||
902 | DELETE FROM [<database-name> .] <table-name> [WHERE <expr>] | ||
903 | } | ||
904 | |||
905 | puts { | ||
906 | <p>The DELETE command is used to remove records from a table. | ||
907 | The command consists of the "DELETE FROM" keywords followed by | ||
908 | the name of the table from which records are to be removed. | ||
909 | </p> | ||
910 | |||
911 | <p>Without a WHERE clause, all rows of the table are removed. | ||
912 | If a WHERE clause is supplied, then only those rows that match | ||
913 | the expression are removed.</p> | ||
914 | } | ||
915 | |||
916 | |||
917 | Section {DETACH DATABASE} detach | ||
918 | |||
919 | Syntax {sql-command} { | ||
920 | DETACH [DATABASE] <database-name> | ||
921 | } | ||
922 | |||
923 | puts { | ||
924 | <p>This statement detaches an additional database connection previously | ||
925 | attached using the <a href="#attach">ATTACH DATABASE</a> statement. It | ||
926 | is possible to have the same database file attached multiple times using | ||
927 | different names, and detaching one connection to a file will leave the | ||
928 | others intact.</p> | ||
929 | |||
930 | <p>This statement will fail if SQLite is in the middle of a transaction.</p> | ||
931 | } | ||
932 | |||
933 | |||
934 | Section {DROP INDEX} dropindex | ||
935 | |||
936 | Syntax {sql-command} { | ||
937 | DROP INDEX [IF EXISTS] [<database-name> .] <index-name> | ||
938 | } | ||
939 | |||
940 | puts { | ||
941 | <p>The DROP INDEX statement removes an index added | ||
942 | with the <a href="#createindex"> | ||
943 | CREATE INDEX</a> statement. The index named is completely removed from | ||
944 | the disk. The only way to recover the index is to reenter the | ||
945 | appropriate CREATE INDEX command.</p> | ||
946 | |||
947 | <p>The DROP INDEX statement does not reduce the size of the database | ||
948 | file in the default mode. | ||
949 | Empty space in the database is retained for later INSERTs. To | ||
950 | remove free space in the database, use the <a href="#vacuum">VACUUM</a> | ||
951 | command. If AUTOVACUUM mode is enabled for a database then space | ||
952 | will be freed automatically by DROP INDEX.</p> | ||
953 | } | ||
954 | |||
955 | |||
956 | Section {DROP TABLE} droptable | ||
957 | |||
958 | Syntax {sql-command} { | ||
959 | DROP TABLE [IF EXISTS] [<database-name>.] <table-name> | ||
960 | } | ||
961 | |||
962 | puts { | ||
963 | <p>The DROP TABLE statement removes a table added with the <a href= | ||
964 | "#createtable">CREATE TABLE</a> statement. The name specified is the | ||
965 | table name. It is completely removed from the database schema and the | ||
966 | disk file. The table can not be recovered. All indices associated | ||
967 | with the table are also deleted.</p> | ||
968 | |||
969 | <p>The DROP TABLE statement does not reduce the size of the database | ||
970 | file in the default mode. Empty space in the database is retained for | ||
971 | later INSERTs. To | ||
972 | remove free space in the database, use the <a href="#vacuum">VACUUM</a> | ||
973 | command. If AUTOVACUUM mode is enabled for a database then space | ||
974 | will be freed automatically by DROP TABLE.</p> | ||
975 | |||
976 | <p>The optional IF EXISTS clause suppresses the error that would normally | ||
977 | result if the table does not exist.</p> | ||
978 | } | ||
979 | |||
980 | |||
981 | Section {DROP TRIGGER} droptrigger | ||
982 | Syntax {sql-statement} { | ||
983 | DROP TRIGGER [IF EXISTS] [<database-name> .] <trigger-name> | ||
984 | } | ||
985 | puts { | ||
986 | <p>The DROP TRIGGER statement removes a trigger created by the | ||
987 | <a href="#createtrigger">CREATE TRIGGER</a> statement. The trigger is | ||
988 | deleted from the database schema. Note that triggers are automatically | ||
989 | dropped when the associated table is dropped.</p> | ||
990 | } | ||
991 | |||
992 | |||
993 | Section {DROP VIEW} dropview | ||
994 | |||
995 | Syntax {sql-command} { | ||
996 | DROP VIEW [IF EXISTS] <view-name> | ||
997 | } | ||
998 | |||
999 | puts { | ||
1000 | <p>The DROP VIEW statement removes a view created by the <a href= | ||
1001 | "#createview">CREATE VIEW</a> statement. The name specified is the | ||
1002 | view name. It is removed from the database schema, but no actual data | ||
1003 | in the underlying base tables is modified.</p> | ||
1004 | } | ||
1005 | |||
1006 | |||
1007 | Section EXPLAIN explain | ||
1008 | |||
1009 | Syntax {sql-statement} { | ||
1010 | EXPLAIN <sql-statement> | ||
1011 | } | ||
1012 | |||
1013 | puts { | ||
1014 | <p>The EXPLAIN command modifier is a non-standard extension. The | ||
1015 | idea comes from a similar command found in PostgreSQL, but the operation | ||
1016 | is completely different.</p> | ||
1017 | |||
1018 | <p>If the EXPLAIN keyword appears before any other SQLite SQL command | ||
1019 | then instead of actually executing the command, the SQLite library will | ||
1020 | report back the sequence of virtual machine instructions it would have | ||
1021 | used to execute the command had the EXPLAIN keyword not been present. | ||
1022 | For additional information about virtual machine instructions see | ||
1023 | the <a href="arch.html">architecture description</a> or the documentation | ||
1024 | on <a href="opcode.html">available opcodes</a> for the virtual machine.</p> | ||
1025 | } | ||
1026 | |||
1027 | |||
1028 | Section expression expr | ||
1029 | |||
1030 | Syntax {expr} { | ||
1031 | <expr> <binary-op> <expr> | | ||
1032 | <expr> [NOT] <like-op> <expr> [ESCAPE <expr>] | | ||
1033 | <unary-op> <expr> | | ||
1034 | ( <expr> ) | | ||
1035 | <column-name> | | ||
1036 | <table-name> . <column-name> | | ||
1037 | <database-name> . <table-name> . <column-name> | | ||
1038 | <literal-value> | | ||
1039 | <parameter> | | ||
1040 | <function-name> ( <expr-list> | STAR ) | | ||
1041 | <expr> ISNULL | | ||
1042 | <expr> NOTNULL | | ||
1043 | <expr> [NOT] BETWEEN <expr> AND <expr> | | ||
1044 | <expr> [NOT] IN ( <value-list> ) | | ||
1045 | <expr> [NOT] IN ( <select-statement> ) | | ||
1046 | <expr> [NOT] IN [<database-name> .] <table-name> | | ||
1047 | [EXISTS] ( <select-statement> ) | | ||
1048 | CASE [<expr>] LP WHEN <expr> THEN <expr> RPPLUS [ELSE <expr>] END | | ||
1049 | CAST ( <expr> AS <type> ) | | ||
1050 | <expr> COLLATE <collation-name> | ||
1051 | } {like-op} { | ||
1052 | LIKE | GLOB | REGEXP | MATCH | ||
1053 | } | ||
1054 | |||
1055 | puts { | ||
1056 | <p>This section is different from the others. Most other sections of | ||
1057 | this document talks about a particular SQL command. This section does | ||
1058 | not talk about a standalone command but about "expressions" which are | ||
1059 | subcomponents of most other commands.</p> | ||
1060 | |||
1061 | <p>SQLite understands the following binary operators, in order from | ||
1062 | highest to lowest precedence:</p> | ||
1063 | |||
1064 | <blockquote><pre> | ||
1065 | <font color="#2c2cf0"><big>|| | ||
1066 | * / % | ||
1067 | + - | ||
1068 | << >> & | | ||
1069 | < <= > >= | ||
1070 | = == != <> </big>IN | ||
1071 | AND | ||
1072 | OR</font> | ||
1073 | </pre></blockquote> | ||
1074 | |||
1075 | <p>Supported unary prefix operators are these:</p> | ||
1076 | |||
1077 | <blockquote><pre> | ||
1078 | <font color="#2c2cf0"><big>- + ! ~ NOT</big></font> | ||
1079 | </pre></blockquote> | ||
1080 | |||
1081 | <p>The COLLATE operator can be thought of as a unary postfix | ||
1082 | operator. The COLLATE operator has the highest precedence. | ||
1083 | It always binds more tightly than any prefix unary operator or | ||
1084 | any binary operator.</p> | ||
1085 | |||
1086 | <p>The unary operator [Operator +] is a no-op. It can be applied | ||
1087 | to strings, numbers, or blobs and it always gives as its result the | ||
1088 | value of the operand.</p> | ||
1089 | |||
1090 | <p>Note that there are two variations of the equals and not equals | ||
1091 | operators. Equals can be either} | ||
1092 | puts "[Operator =] or [Operator ==]. | ||
1093 | The non-equals operator can be either | ||
1094 | [Operator !=] or [Operator {<>}]. | ||
1095 | The [Operator ||] operator is \"concatenate\" - it joins together | ||
1096 | the two strings of its operands. | ||
1097 | The operator [Operator %] outputs the remainder of its left | ||
1098 | operand modulo its right operand.</p> | ||
1099 | |||
1100 | <p>The result of any binary operator is a numeric value, except | ||
1101 | for the [Operator ||] concatenation operator which gives a string | ||
1102 | result.</p>" | ||
1103 | |||
1104 | puts { | ||
1105 | |||
1106 | <a name="literal_value"></a> | ||
1107 | <p> | ||
1108 | A literal value is an integer number or a floating point number. | ||
1109 | Scientific notation is supported. The "." character is always used | ||
1110 | as the decimal point even if the locale setting specifies "," for | ||
1111 | this role - the use of "," for the decimal point would result in | ||
1112 | syntactic ambiguity. A string constant is formed by enclosing the | ||
1113 | string in single quotes ('). A single quote within the string can | ||
1114 | be encoded by putting two single quotes in a row - as in Pascal. | ||
1115 | C-style escapes using the backslash character are not supported because | ||
1116 | they are not standard SQL. | ||
1117 | BLOB literals are string literals containing hexadecimal data and | ||
1118 | preceded by a single "x" or "X" character. For example:</p> | ||
1119 | |||
1120 | <blockquote><pre> | ||
1121 | X'53514C697465' | ||
1122 | </pre></blockquote> | ||
1123 | |||
1124 | <p> | ||
1125 | A literal value can also be the token "NULL". | ||
1126 | </p> | ||
1127 | |||
1128 | <p> | ||
1129 | A parameter specifies a placeholder in the expression for a literal | ||
1130 | value that is filled in at runtime using the | ||
1131 | <a href="capi3ref.html#sqlite3_bind_int">sqlite3_bind</a> API. | ||
1132 | Parameters can take several forms: | ||
1133 | </p | ||
1134 | |||
1135 | <blockquote> | ||
1136 | <table class="pdf_functions"> | ||
1137 | <tr> | ||
1138 | <td align="right" valign="top"><b>?</b><i>NNN</i></td><td width="20"></td> | ||
1139 | <td>A question mark followed by a number <i>NNN</i> holds a spot for the | ||
1140 | NNN-th parameter. NNN must be between 1 and 999.</td> | ||
1141 | </tr> | ||
1142 | <tr> | ||
1143 | <td align="right" valign="top"><b>?</b></td><td width="20"></td> | ||
1144 | <td>A question mark that is not followed by a number holds a spot for | ||
1145 | the next unused parameter.</td> | ||
1146 | </tr> | ||
1147 | <tr> | ||
1148 | <td align="right" valign="top"><b>:</b><i>AAAA</i></td><td width="20"></td> | ||
1149 | <td>A colon followed by an identifier name holds a spot for a named | ||
1150 | parameter with the name AAAA. Named parameters are also numbered. | ||
1151 | The number assigned is the next unused number. To avoid confusion, | ||
1152 | it is best to avoid mixing named and numbered parameters.</td> | ||
1153 | </tr> | ||
1154 | <tr> | ||
1155 | <td align="right" valign="top"><b>@</b><i>AAAA</i></td><td width="20"></td> | ||
1156 | <td>An "at" sign works exactly like a colon.</td> | ||
1157 | </tr> | ||
1158 | <tr> | ||
1159 | <td align="right" valign="top"><b>$</b><i>AAAA</i></td><td width="20"></td> | ||
1160 | <td>A dollar-sign followed by an identifier name also holds a spot for a named | ||
1161 | parameter with the name AAAA. The identifier name in this case can include | ||
1162 | one or more occurances of "::" and a suffix enclosed in "(...)" containing | ||
1163 | any text at all. This syntax is the form of a variable name in the Tcl | ||
1164 | programming language.</td> | ||
1165 | </tr> | ||
1166 | </table> | ||
1167 | </blockquote> | ||
1168 | |||
1169 | <p>Parameters that are not assigned values using | ||
1170 | <a href="capi3ref.html#sqlite3_bind_int">sqlite3_bind</a> are treated | ||
1171 | as NULL.</p> | ||
1172 | |||
1173 | <a name="like"></a> | ||
1174 | <p>The LIKE operator does a pattern matching comparison. The operand | ||
1175 | to the right contains the pattern, the left hand operand contains the | ||
1176 | string to match against the pattern. | ||
1177 | } | ||
1178 | puts "A percent symbol [Operator %] in the pattern matches any | ||
1179 | sequence of zero or more characters in the string. An underscore | ||
1180 | [Operator _] in the pattern matches any single character in the | ||
1181 | string. Any other character matches itself or it's lower/upper case | ||
1182 | equivalent (i.e. case-insensitive matching). (A bug: SQLite only | ||
1183 | understands upper/lower case for 7-bit Latin characters. Hence the | ||
1184 | LIKE operator is case sensitive for 8-bit iso8859 characters or UTF-8 | ||
1185 | characters. For example, the expression <b>'a' LIKE 'A'</b> | ||
1186 | is TRUE but <b>'æ' LIKE 'Æ'</b> is FALSE.).</p>" | ||
1187 | |||
1188 | puts { | ||
1189 | <p>If the optional ESCAPE clause is present, then the expression | ||
1190 | following the ESCAPE keyword must evaluate to a string consisting of | ||
1191 | a single character. This character may be used in the LIKE pattern | ||
1192 | to include literal percent or underscore characters. The escape | ||
1193 | character followed by a percent symbol, underscore or itself matches a | ||
1194 | literal percent symbol, underscore or escape character in the string, | ||
1195 | respectively. The infix LIKE operator is implemented by calling the | ||
1196 | user function <a href="#likeFunc"> like(<i>X</i>,<i>Y</i>)</a>.</p> | ||
1197 | } | ||
1198 | |||
1199 | puts { | ||
1200 | The LIKE operator is not case sensitive and will match upper case | ||
1201 | characters on one side against lower case characters on the other. | ||
1202 | (A bug: SQLite only understands upper/lower case for 7-bit Latin | ||
1203 | characters. Hence the LIKE operator is case sensitive for 8-bit | ||
1204 | iso8859 characters or UTF-8 characters. For example, the expression | ||
1205 | <b>'a' LIKE 'A'</b> is TRUE but | ||
1206 | <b>'æ' LIKE 'Æ'</b> is FALSE.).</p> | ||
1207 | |||
1208 | <p>The infix LIKE | ||
1209 | operator is implemented by calling the user function <a href="#likeFunc"> | ||
1210 | like(<i>X</i>,<i>Y</i>)</a>. If an ESCAPE clause is present, it adds | ||
1211 | a third parameter to the function call. If the functionality of LIKE can be | ||
1212 | overridden by defining an alternative implementation of the | ||
1213 | like() SQL function.</p> | ||
1214 | </p> | ||
1215 | |||
1216 | <a name="glob"></a> | ||
1217 | <p>The GLOB operator is similar to LIKE but uses the Unix | ||
1218 | file globbing syntax for its wildcards. Also, GLOB is case | ||
1219 | sensitive, unlike LIKE. Both GLOB and LIKE may be preceded by | ||
1220 | the NOT keyword to invert the sense of the test. The infix GLOB | ||
1221 | operator is implemented by calling the user function <a href="#globFunc"> | ||
1222 | glob(<i>X</i>,<i>Y</i>)</a> and can be modified by overriding | ||
1223 | that function.</p> | ||
1224 | |||
1225 | <a name="regexp"></a> | ||
1226 | <p>The REGEXP operator is a special syntax for the regexp() | ||
1227 | user function. No regexp() user function is defined by default | ||
1228 | and so use of the REGEXP operator will normally result in an | ||
1229 | error message. If a user-defined function named "regexp" | ||
1230 | is added at run-time, that function will be called in order | ||
1231 | to implement the REGEXP operator.</p> | ||
1232 | |||
1233 | <a name="match"></a> | ||
1234 | <p>The MATCH operator is a special syntax for the match() | ||
1235 | user function. The default match() function implementation | ||
1236 | raises and exception and is not really useful for anything. | ||
1237 | But extensions can override the match() function with more | ||
1238 | helpful logic.</p> | ||
1239 | |||
1240 | <p>A column name can be any of the names defined in the CREATE TABLE | ||
1241 | statement or one of the following special identifiers: "<b>ROWID</b>", | ||
1242 | "<b>OID</b>", or "<b>_ROWID_</b>". | ||
1243 | These special identifiers all describe the | ||
1244 | unique integer key (the "row key") associated with every | ||
1245 | row of every table. | ||
1246 | The special identifiers only refer to the row key if the CREATE TABLE | ||
1247 | statement does not define a real column with the same name. Row keys | ||
1248 | act like read-only columns. A row key can be used anywhere a regular | ||
1249 | column can be used, except that you cannot change the value | ||
1250 | of a row key in an UPDATE or INSERT statement. | ||
1251 | "SELECT * ..." does not return the row key.</p> | ||
1252 | |||
1253 | <p>SELECT statements can appear in expressions as either the | ||
1254 | right-hand operand of the IN operator, as a scalar quantity, or | ||
1255 | as the operand of an EXISTS operator. | ||
1256 | As a scalar quantity or the operand of an IN operator, | ||
1257 | the SELECT should have only a single column in its | ||
1258 | result. Compound SELECTs (connected with keywords like UNION or | ||
1259 | EXCEPT) are allowed. | ||
1260 | With the EXISTS operator, the columns in the result set of the SELECT are | ||
1261 | ignored and the expression returns TRUE if one or more rows exist | ||
1262 | and FALSE if the result set is empty. | ||
1263 | If no terms in the SELECT expression refer to value in the containing | ||
1264 | query, then the expression is evaluated once prior to any other | ||
1265 | processing and the result is reused as necessary. If the SELECT expression | ||
1266 | does contain variables from the outer query, then the SELECT is reevaluated | ||
1267 | every time it is needed.</p> | ||
1268 | |||
1269 | <p>When a SELECT is the right operand of the IN operator, the IN | ||
1270 | operator returns TRUE if the result of the left operand is any of | ||
1271 | the values generated by the select. The IN operator may be preceded | ||
1272 | by the NOT keyword to invert the sense of the test.</p> | ||
1273 | |||
1274 | <p>When a SELECT appears within an expression but is not the right | ||
1275 | operand of an IN operator, then the first row of the result of the | ||
1276 | SELECT becomes the value used in the expression. If the SELECT yields | ||
1277 | more than one result row, all rows after the first are ignored. If | ||
1278 | the SELECT yields no rows, then the value of the SELECT is NULL.</p> | ||
1279 | |||
1280 | <p>A CAST expression changes the datatype of the <expr> into the | ||
1281 | type specified by <type>. | ||
1282 | <type> can be any non-empty type name that is valid | ||
1283 | for the type in a column definition of a CREATE TABLE statement.</p> | ||
1284 | |||
1285 | <p>Both simple and aggregate functions are supported. A simple | ||
1286 | function can be used in any expression. Simple functions return | ||
1287 | a result immediately based on their inputs. Aggregate functions | ||
1288 | may only be used in a SELECT statement. Aggregate functions compute | ||
1289 | their result across all rows of the result set.</p> | ||
1290 | |||
1291 | <a name="corefunctions"></a> | ||
1292 | <b>Core Functions</b> | ||
1293 | |||
1294 | <p>The core functions shown below are available by default. Additional | ||
1295 | functions may be written in C and added to the database engine using | ||
1296 | the <a href="capi3ref.html#cfunc">sqlite3_create_function()</a> | ||
1297 | API.</p> | ||
1298 | |||
1299 | <table border=0 cellpadding=10 class="pdf_functions"> | ||
1300 | <tr> | ||
1301 | <td valign="top" align="right" width=120>abs(<i>X</i>)</td> | ||
1302 | <td valign="top">Return the absolute value of argument <i>X</i>.</td> | ||
1303 | </tr> | ||
1304 | |||
1305 | <tr> | ||
1306 | <td valign="top" align="right">coalesce(<i>X</i>,<i>Y</i>,...)</td> | ||
1307 | <td valign="top">Return a copy of the first non-NULL argument. If | ||
1308 | all arguments are NULL then NULL is returned. There must be at least | ||
1309 | 2 arguments.</td> | ||
1310 | </tr> | ||
1311 | |||
1312 | <tr> | ||
1313 | <td valign="top" align="right"> | ||
1314 | <a name="globFunc"></a> | ||
1315 | glob(<i>X</i>,<i>Y</i>)</td> | ||
1316 | <td valign="top">This function is used to implement the | ||
1317 | "<b>X GLOB Y</b>" syntax of SQLite. The | ||
1318 | <a href="capi3ref.html#sqlite3_create_function">sqlite3_create_function()</a> | ||
1319 | interface can | ||
1320 | be used to override this function and thereby change the operation | ||
1321 | of the <a href="#globFunc">GLOB</a> operator.</td> | ||
1322 | </tr> | ||
1323 | |||
1324 | <tr> | ||
1325 | <td valign="top" align="right">ifnull(<i>X</i>,<i>Y</i>)</td> | ||
1326 | <td valign="top">Return a copy of the first non-NULL argument. If | ||
1327 | both arguments are NULL then NULL is returned. This behaves the same as | ||
1328 | <b>coalesce()</b> above.</td> | ||
1329 | </tr> | ||
1330 | |||
1331 | <tr> | ||
1332 | <td valign="top" align="right"> | ||
1333 | <a name="hexFunc"> | ||
1334 | hex(<i>X</i>)</td> | ||
1335 | <td valign="top">The argument is interpreted as a BLOB. The result | ||
1336 | is a hexadecimal rendering of the content of that blob.</td> | ||
1337 | </tr> | ||
1338 | |||
1339 | <tr> | ||
1340 | <td valign="top" align="right">last_insert_rowid()</td> | ||
1341 | <td valign="top">Return the <a href="lang_createtable.html#rowid">ROWID</a> | ||
1342 | of the last row insert from this | ||
1343 | connection to the database. This is the same value that would be returned | ||
1344 | from the <b>sqlite_last_insert_rowid()</b> API function.</td> | ||
1345 | </tr> | ||
1346 | |||
1347 | <tr> | ||
1348 | <td valign="top" align="right">length(<i>X</i>)</td> | ||
1349 | <td valign="top">Return the string length of <i>X</i> in characters. | ||
1350 | If SQLite is configured to support UTF-8, then the number of UTF-8 | ||
1351 | characters is returned, not the number of bytes.</td> | ||
1352 | </tr> | ||
1353 | |||
1354 | <tr> | ||
1355 | <td valign="top" align="right"> | ||
1356 | <a name="likeFunc"></a> | ||
1357 | like(<i>X</i>,<i>Y</i>)<br> | ||
1358 | like(<i>X</i>,<i>Y</i>,<i>Z</i>)</td> | ||
1359 | <td valign="top"> | ||
1360 | This function is used to implement the "<b>X LIKE Y [ESCAPE Z]</b>" | ||
1361 | syntax of SQL. If the optional ESCAPE clause is present, then the | ||
1362 | user-function is invoked with three arguments. Otherwise, it is | ||
1363 | invoked with two arguments only. The | ||
1364 | <a href="capi3ref.html#sqlite3_create_function"> | ||
1365 | sqlite_create_function()</a> interface can be used to override this | ||
1366 | function and thereby change the operation of the <a | ||
1367 | href= "#like">LIKE</a> operator. When doing this, it may be important | ||
1368 | to override both the two and three argument versions of the like() | ||
1369 | function. Otherwise, different code may be called to implement the | ||
1370 | LIKE operator depending on whether or not an ESCAPE clause was | ||
1371 | specified.</td> | ||
1372 | </tr> | ||
1373 | |||
1374 | <tr> | ||
1375 | <td valign="top" align="right">load_extension(<i>X</i>)<br> | ||
1376 | load_extension(<i>X</i>,<i>Y</i>)</td> | ||
1377 | <td valign="top">Load SQLite extensions out of the shared library | ||
1378 | file named <i>X</i> using the entry point <i>Y</i>. The result | ||
1379 | is a NULL. If <i>Y</i> is omitted then the default entry point | ||
1380 | of <b>sqlite3_extension_init</b> is used. This function raises | ||
1381 | an exception if the extension fails to load or initialize correctly. | ||
1382 | |||
1383 | <p>This function will fail if the extension attempts to modify | ||
1384 | or delete a SQL function or collating sequence. The | ||
1385 | extension can add new functions or collating sequences, but cannot | ||
1386 | modify or delete existing functions or collating sequences because | ||
1387 | those functions and/or collating sequences might be used elsewhere | ||
1388 | in the currently running SQL statement. To load an extension that | ||
1389 | changes or deletes functions or collating sequences, use the | ||
1390 | <a href="capi3ref.html#sqlite3_load_extension">sqlite3_load_extension()</a> | ||
1391 | C-language API.</p> | ||
1392 | </tr> | ||
1393 | |||
1394 | <tr> | ||
1395 | <td valign="top" align="right">lower(<i>X</i>)</td> | ||
1396 | <td valign="top">Return a copy of string <i>X</i> will all characters | ||
1397 | converted to lower case. The C library <b>tolower()</b> routine is used | ||
1398 | for the conversion, which means that this function might not | ||
1399 | work correctly on UTF-8 characters.</td> | ||
1400 | </tr> | ||
1401 | |||
1402 | <tr> | ||
1403 | <td valign="top" align="right"> | ||
1404 | <a name="ltrimFunc"> | ||
1405 | ltrim(<i>X</i>)<br>ltrim(<i>X</i>,<i>Y</i>)</td> | ||
1406 | <td valign="top">Return a string formed by removing any and all | ||
1407 | characters that appear in <i>Y</i> from the left side of <i>X</i>. | ||
1408 | If the <i>Y</i> argument is omitted, spaces are removed.</td> | ||
1409 | </tr> | ||
1410 | |||
1411 | |||
1412 | <tr> | ||
1413 | <td valign="top" align="right">max(<i>X</i>,<i>Y</i>,...)</td> | ||
1414 | <td valign="top">Return the argument with the maximum value. Arguments | ||
1415 | may be strings in addition to numbers. The maximum value is determined | ||
1416 | by the usual sort order. Note that <b>max()</b> is a simple function when | ||
1417 | it has 2 or more arguments but converts to an aggregate function if given | ||
1418 | only a single argument.</td> | ||
1419 | </tr> | ||
1420 | |||
1421 | <tr> | ||
1422 | <td valign="top" align="right">min(<i>X</i>,<i>Y</i>,...)</td> | ||
1423 | <td valign="top">Return the argument with the minimum value. Arguments | ||
1424 | may be strings in addition to numbers. The minimum value is determined | ||
1425 | by the usual sort order. Note that <b>min()</b> is a simple function when | ||
1426 | it has 2 or more arguments but converts to an aggregate function if given | ||
1427 | only a single argument.</td> | ||
1428 | </tr> | ||
1429 | |||
1430 | <tr> | ||
1431 | <td valign="top" align="right">nullif(<i>X</i>,<i>Y</i>)</td> | ||
1432 | <td valign="top">Return the first argument if the arguments are different, | ||
1433 | otherwise return NULL.</td> | ||
1434 | </tr> | ||
1435 | |||
1436 | <tr> | ||
1437 | <td valign="top" align="right">quote(<i>X</i>)</td> | ||
1438 | <td valign="top">This routine returns a string which is the value of | ||
1439 | its argument suitable for inclusion into another SQL statement. | ||
1440 | Strings are surrounded by single-quotes with escapes on interior quotes | ||
1441 | as needed. BLOBs are encoded as hexadecimal literals. | ||
1442 | The current implementation of VACUUM uses this function. The function | ||
1443 | is also useful when writing triggers to implement undo/redo functionality. | ||
1444 | </td> | ||
1445 | </tr> | ||
1446 | |||
1447 | <tr> | ||
1448 | <td valign="top" align="right">random(*)</td> | ||
1449 | <td valign="top">Return a pseudo-random integer | ||
1450 | between -9223372036854775808 and +9223372036854775807.</td> | ||
1451 | </tr> | ||
1452 | |||
1453 | <tr> | ||
1454 | <td valign="top" align="right"> | ||
1455 | <a name="replaceFunc"> | ||
1456 | replace(<i>X</i>,<i>Y</i>,<i>Z</i>)</td> | ||
1457 | <td valign="top">Return a string formed by substituting string <i>Z</i> for | ||
1458 | every occurrance of string <i>Y</i> in string <i>X</i>. The BINARY | ||
1459 | collating sequence is used for comparisons.</td> | ||
1460 | </tr> | ||
1461 | |||
1462 | <tr> | ||
1463 | <td valign="top" align="right"> | ||
1464 | <a name="randomblobFunc"> | ||
1465 | randomblob(<i>N</i>)</td> | ||
1466 | <td valign="top">Return a <i>N</i>-byte blob containing pseudo-random bytes. | ||
1467 | <i>N</i> should be a postive integer.</td> | ||
1468 | </tr> | ||
1469 | |||
1470 | <tr> | ||
1471 | <td valign="top" align="right">round(<i>X</i>)<br>round(<i>X</i>,<i>Y</i>)</td> | ||
1472 | <td valign="top">Round off the number <i>X</i> to <i>Y</i> digits to the | ||
1473 | right of the decimal point. If the <i>Y</i> argument is omitted, 0 is | ||
1474 | assumed.</td> | ||
1475 | </tr> | ||
1476 | |||
1477 | <tr> | ||
1478 | <td valign="top" align="right"> | ||
1479 | <a name="rtrimFunc"> | ||
1480 | rtrim(<i>X</i>)<br>rtrim(<i>X</i>,<i>Y</i>)</td> | ||
1481 | <td valign="top">Return a string formed by removing any and all | ||
1482 | characters that appear in <i>Y</i> from the right side of <i>X</i>. | ||
1483 | If the <i>Y</i> argument is omitted, spaces are removed.</td> | ||
1484 | </tr> | ||
1485 | |||
1486 | <tr> | ||
1487 | <td valign="top" align="right">soundex(<i>X</i>)</td> | ||
1488 | <td valign="top">Compute the soundex encoding of the string <i>X</i>. | ||
1489 | The string "?000" is returned if the argument is NULL. | ||
1490 | This function is omitted from SQLite by default. | ||
1491 | It is only available the -DSQLITE_SOUNDEX=1 compiler option | ||
1492 | is used when SQLite is built.</td> | ||
1493 | </tr> | ||
1494 | |||
1495 | <tr> | ||
1496 | <td valign="top" align="right">sqlite_version(*)</td> | ||
1497 | <td valign="top">Return the version string for the SQLite library | ||
1498 | that is running. Example: "2.8.0"</td> | ||
1499 | </tr> | ||
1500 | |||
1501 | <tr> | ||
1502 | <td valign="top" align="right">substr(<i>X</i>,<i>Y</i>,<i>Z</i>)</td> | ||
1503 | <td valign="top">Return a substring of input string <i>X</i> that begins | ||
1504 | with the <i>Y</i>-th character and which is <i>Z</i> characters long. | ||
1505 | The left-most character of <i>X</i> is number 1. If <i>Y</i> is negative | ||
1506 | the the first character of the substring is found by counting from the | ||
1507 | right rather than the left. If <i>X</i> is string | ||
1508 | then characters indices refer to actual UTF-8 characters. If | ||
1509 | <i>X</i> is a BLOB then the indices refer to bytes.</td> | ||
1510 | </tr> | ||
1511 | |||
1512 | <tr> | ||
1513 | <td valign="top" align="right"> | ||
1514 | <a name="trimFunc"> | ||
1515 | trim(<i>X</i>)<br>trim(<i>X</i>,<i>Y</i>)</td> | ||
1516 | <td valign="top">Return a string formed by removing any and all | ||
1517 | characters that appear in <i>Y</i> from both ends of <i>X</i>. | ||
1518 | If the <i>Y</i> argument is omitted, spaces are removed.</td> | ||
1519 | </tr> | ||
1520 | |||
1521 | |||
1522 | <tr> | ||
1523 | <td valign="top" align="right">typeof(<i>X</i>)</td> | ||
1524 | <td valign="top">Return the type of the expression <i>X</i>. The only | ||
1525 | return values are "null", "integer", "real", "text", and "blob". | ||
1526 | SQLite's type handling is | ||
1527 | explained in <a href="datatype3.html">Datatypes in SQLite Version 3</a>.</td> | ||
1528 | </tr> | ||
1529 | |||
1530 | <tr> | ||
1531 | <td valign="top" align="right">upper(<i>X</i>)</td> | ||
1532 | <td valign="top">Return a copy of input string <i>X</i> converted to all | ||
1533 | upper-case letters. The implementation of this function uses the C library | ||
1534 | routine <b>toupper()</b> which means it may not work correctly on | ||
1535 | UTF-8 strings.</td> | ||
1536 | </tr> | ||
1537 | |||
1538 | <tr> | ||
1539 | <td valign="top" align="right">zeroblob(<i>N</i>)</td> | ||
1540 | <td valign="top"><a name="zeroblob"> | ||
1541 | Return a BLOB consisting of N bytes of 0x00. SQLite | ||
1542 | manages these zeroblobs very efficiently. Zeroblobs can be used to | ||
1543 | reserve space for a BLOB that is later written using | ||
1544 | <a href="capi3ref.html#sqlite3_blob_open">incremental BLOB I/O</a>.</td> | ||
1545 | </tr> | ||
1546 | |||
1547 | </table> | ||
1548 | |||
1549 | <b>Date And Time Functions</b> | ||
1550 | |||
1551 | <p>Date and time functions are documented in the | ||
1552 | <a href="http://www.sqlite.org/cvstrac/wiki?p=DateAndTimeFunctions"> | ||
1553 | SQLite Wiki</a>.</p> | ||
1554 | |||
1555 | <a name="aggregatefunctions"></a> | ||
1556 | <b>Aggregate Functions</b> | ||
1557 | |||
1558 | <p> | ||
1559 | The aggregate functions shown below are available by default. Additional | ||
1560 | aggregate functions written in C may be added using the | ||
1561 | <a href="capi3ref.html#sqlite3_create_function">sqlite3_create_function()</a> | ||
1562 | API.</p> | ||
1563 | |||
1564 | <p> | ||
1565 | In any aggregate function that takes a single argument, that argument | ||
1566 | can be preceeded by the keyword DISTINCT. In such cases, duplicate | ||
1567 | elements are filtered before being passed into the aggregate function. | ||
1568 | For example, the function "count(distinct X)" will return the number | ||
1569 | of distinct values of column X instead of the total number of non-null | ||
1570 | values in column X. | ||
1571 | </p> | ||
1572 | |||
1573 | <table border=0 cellpadding=10 class="pdf_functions"> | ||
1574 | <tr> | ||
1575 | <td valign="top" align="right" width=120>avg(<i>X</i>)</td> | ||
1576 | <td valign="top">Return the average value of all non-NULL <i>X</i> within a | ||
1577 | group. String and BLOB values that do not look like numbers are | ||
1578 | interpreted as 0. | ||
1579 | The result of avg() is always a floating point value even if all | ||
1580 | inputs are integers. </p></td> | ||
1581 | </tr> | ||
1582 | |||
1583 | <tr> | ||
1584 | <td valign="top" align="right">count(<i>X</i>)<br>count(*)</td> | ||
1585 | <td valign="top">The first form return a count of the number of times | ||
1586 | that <i>X</i> is not NULL in a group. The second form (with no argument) | ||
1587 | returns the total number of rows in the group.</td> | ||
1588 | </tr> | ||
1589 | |||
1590 | <tr> | ||
1591 | <td valign="top" align="right">max(<i>X</i>)</td> | ||
1592 | <td valign="top">Return the maximum value of all values in the group. | ||
1593 | The usual sort order is used to determine the maximum.</td> | ||
1594 | </tr> | ||
1595 | |||
1596 | <tr> | ||
1597 | <td valign="top" align="right">min(<i>X</i>)</td> | ||
1598 | <td valign="top">Return the minimum non-NULL value of all values in the group. | ||
1599 | The usual sort order is used to determine the minimum. NULL is only returned | ||
1600 | if all values in the group are NULL.</td> | ||
1601 | </tr> | ||
1602 | |||
1603 | <tr> | ||
1604 | <td valign="top" align="right">sum(<i>X</i>)<br>total(<i>X</i>)</td> | ||
1605 | <td valign="top">Return the numeric sum of all non-NULL values in the group. | ||
1606 | If there are no non-NULL input rows then sum() returns | ||
1607 | NULL but total() returns 0.0. | ||
1608 | NULL is not normally a helpful result for the sum of no rows | ||
1609 | but the SQL standard requires it and most other | ||
1610 | SQL database engines implement sum() that way so SQLite does it in the | ||
1611 | same way in order to be compatible. The non-standard total() function | ||
1612 | is provided as a convenient way to work around this design problem | ||
1613 | in the SQL language.</p> | ||
1614 | |||
1615 | <p>The result of total() is always a floating point value. | ||
1616 | The result of sum() is an integer value if all non-NULL inputs are integers. | ||
1617 | If any input to sum() is neither an integer or a NULL | ||
1618 | then sum() returns a floating point value | ||
1619 | which might be an approximation to the true sum.</p> | ||
1620 | |||
1621 | <p>Sum() will throw an "integer overflow" exception if all inputs | ||
1622 | are integers or NULL | ||
1623 | and an integer overflow occurs at any point during the computation. | ||
1624 | Total() never throws an exception.</p> | ||
1625 | </tr> | ||
1626 | </table> | ||
1627 | } | ||
1628 | |||
1629 | |||
1630 | Section INSERT insert | ||
1631 | |||
1632 | Syntax {sql-statement} { | ||
1633 | INSERT [OR <conflict-algorithm>] INTO [<database-name> .] <table-name> [(<column-list>)] VALUES(<value-list>) | | ||
1634 | INSERT [OR <conflict-algorithm>] INTO [<database-name> .] <table-name> [(<column-list>)] <select-statement> | ||
1635 | } | ||
1636 | |||
1637 | puts { | ||
1638 | <p>The INSERT statement comes in two basic forms. The first form | ||
1639 | (with the "VALUES" keyword) creates a single new row in an existing table. | ||
1640 | If no column-list is specified then the number of values must | ||
1641 | be the same as the number of columns in the table. If a column-list | ||
1642 | is specified, then the number of values must match the number of | ||
1643 | specified columns. Columns of the table that do not appear in the | ||
1644 | column list are filled with the default value, or with NULL if no | ||
1645 | default value is specified. | ||
1646 | </p> | ||
1647 | |||
1648 | <p>The second form of the INSERT statement takes it data from a | ||
1649 | SELECT statement. The number of columns in the result of the | ||
1650 | SELECT must exactly match the number of columns in the table if | ||
1651 | no column list is specified, or it must match the number of columns | ||
1652 | name in the column list. A new entry is made in the table | ||
1653 | for every row of the SELECT result. The SELECT may be simple | ||
1654 | or compound.</p> | ||
1655 | |||
1656 | <p>The optional conflict-clause allows the specification of an alternative | ||
1657 | constraint conflict resolution algorithm to use during this one command. | ||
1658 | See the section titled | ||
1659 | <a href="#conflict">ON CONFLICT</a> for additional information. | ||
1660 | For compatibility with MySQL, the parser allows the use of the | ||
1661 | single keyword <a href="#replace">REPLACE</a> as an alias for "INSERT OR REPLACE". | ||
1662 | </p> | ||
1663 | } | ||
1664 | |||
1665 | |||
1666 | Section {ON CONFLICT clause} conflict | ||
1667 | |||
1668 | Syntax {conflict-clause} { | ||
1669 | ON CONFLICT <conflict-algorithm> | ||
1670 | } {conflict-algorithm} { | ||
1671 | ROLLBACK | ABORT | FAIL | IGNORE | REPLACE | ||
1672 | } | ||
1673 | |||
1674 | puts { | ||
1675 | <p>The ON CONFLICT clause is not a separate SQL command. It is a | ||
1676 | non-standard clause that can appear in many other SQL commands. | ||
1677 | It is given its own section in this document because it is not | ||
1678 | part of standard SQL and therefore might not be familiar.</p> | ||
1679 | |||
1680 | <p>The syntax for the ON CONFLICT clause is as shown above for | ||
1681 | the CREATE TABLE command. For the INSERT and | ||
1682 | UPDATE commands, the keywords "ON CONFLICT" are replaced by "OR", to make | ||
1683 | the syntax seem more natural. For example, instead of | ||
1684 | "INSERT ON CONFLICT IGNORE" we have "INSERT OR IGNORE". | ||
1685 | The keywords change but the meaning of the clause is the same | ||
1686 | either way.</p> | ||
1687 | |||
1688 | <p>The ON CONFLICT clause specifies an algorithm used to resolve | ||
1689 | constraint conflicts. There are five choices: ROLLBACK, ABORT, | ||
1690 | FAIL, IGNORE, and REPLACE. The default algorithm is ABORT. This | ||
1691 | is what they mean:</p> | ||
1692 | |||
1693 | <dl> | ||
1694 | <dt><b>ROLLBACK</b></dt> | ||
1695 | <dd><p>When a constraint violation occurs, an immediate ROLLBACK | ||
1696 | occurs, thus ending the current transaction, and the command aborts | ||
1697 | with a return code of SQLITE_CONSTRAINT. If no transaction is | ||
1698 | active (other than the implied transaction that is created on every | ||
1699 | command) then this algorithm works the same as ABORT.</p></dd> | ||
1700 | |||
1701 | <dt><b>ABORT</b></dt> | ||
1702 | <dd><p>When a constraint violation occurs, the command backs out | ||
1703 | any prior changes it might have made and aborts with a return code | ||
1704 | of SQLITE_CONSTRAINT. But no ROLLBACK is executed so changes | ||
1705 | from prior commands within the same transaction | ||
1706 | are preserved. This is the default behavior.</p></dd> | ||
1707 | |||
1708 | <dt><b>FAIL</b></dt> | ||
1709 | <dd><p>When a constraint violation occurs, the command aborts with a | ||
1710 | return code SQLITE_CONSTRAINT. But any changes to the database that | ||
1711 | the command made prior to encountering the constraint violation | ||
1712 | are preserved and are not backed out. For example, if an UPDATE | ||
1713 | statement encountered a constraint violation on the 100th row that | ||
1714 | it attempts to update, then the first 99 row changes are preserved | ||
1715 | but changes to rows 100 and beyond never occur.</p></dd> | ||
1716 | |||
1717 | <dt><b>IGNORE</b></dt> | ||
1718 | <dd><p>When a constraint violation occurs, the one row that contains | ||
1719 | the constraint violation is not inserted or changed. But the command | ||
1720 | continues executing normally. Other rows before and after the row that | ||
1721 | contained the constraint violation continue to be inserted or updated | ||
1722 | normally. No error is returned.</p></dd> | ||
1723 | |||
1724 | <dt><b>REPLACE</b></dt> | ||
1725 | <dd><p>When a UNIQUE constraint violation occurs, the pre-existing rows | ||
1726 | that are causing the constraint violation are removed prior to inserting | ||
1727 | or updating the current row. Thus the insert or update always occurs. | ||
1728 | The command continues executing normally. No error is returned. | ||
1729 | If a NOT NULL constraint violation occurs, the NULL value is replaced | ||
1730 | by the default value for that column. If the column has no default | ||
1731 | value, then the ABORT algorithm is used. If a CHECK constraint violation | ||
1732 | occurs then the IGNORE algorithm is used.</p> | ||
1733 | |||
1734 | <p>When this conflict resolution strategy deletes rows in order to | ||
1735 | satisfy a constraint, it does not invoke delete triggers on those | ||
1736 | rows. This behavior might change in a future release.</p> | ||
1737 | </dl> | ||
1738 | |||
1739 | <p>The algorithm specified in the OR clause of a INSERT or UPDATE | ||
1740 | overrides any algorithm specified in a CREATE TABLE. | ||
1741 | If no algorithm is specified anywhere, the ABORT algorithm is used.</p> | ||
1742 | } | ||
1743 | |||
1744 | Section REINDEX reindex | ||
1745 | |||
1746 | Syntax {sql-statement} { | ||
1747 | REINDEX <collation name> | ||
1748 | } | ||
1749 | Syntax {sql-statement} { | ||
1750 | REINDEX [<database-name> .] <table/index-name> | ||
1751 | } | ||
1752 | |||
1753 | puts { | ||
1754 | <p>The REINDEX command is used to delete and recreate indices from scratch. | ||
1755 | This is useful when the definition of a collation sequence has changed. | ||
1756 | </p> | ||
1757 | |||
1758 | <p>In the first form, all indices in all attached databases that use the | ||
1759 | named collation sequence are recreated. In the second form, if | ||
1760 | <i>[database-name.]table/index-name</i> identifies a table, then all indices | ||
1761 | associated with the table are rebuilt. If an index is identified, then only | ||
1762 | this specific index is deleted and recreated. | ||
1763 | </p> | ||
1764 | |||
1765 | <p>If no <i>database-name</i> is specified and there exists both a table or | ||
1766 | index and a collation sequence of the specified name, then indices associated | ||
1767 | with the collation sequence only are reconstructed. This ambiguity may be | ||
1768 | dispelled by always specifying a <i>database-name</i> when reindexing a | ||
1769 | specific table or index. | ||
1770 | } | ||
1771 | |||
1772 | Section REPLACE replace | ||
1773 | |||
1774 | Syntax {sql-statement} { | ||
1775 | REPLACE INTO [<database-name> .] <table-name> [( <column-list> )] VALUES ( <value-list> ) | | ||
1776 | REPLACE INTO [<database-name> .] <table-name> [( <column-list> )] <select-statement> | ||
1777 | } | ||
1778 | |||
1779 | puts { | ||
1780 | <p>The REPLACE command is an alias for the "INSERT OR REPLACE" variant | ||
1781 | of the <a href="#insert">INSERT</a> command. This alias is provided for | ||
1782 | compatibility with MySQL. See the | ||
1783 | <a href="#insert">INSERT</a> command documentation for additional | ||
1784 | information.</p> | ||
1785 | } | ||
1786 | |||
1787 | |||
1788 | Section SELECT select | ||
1789 | |||
1790 | Syntax {sql-statement} { | ||
1791 | SELECT [ALL | DISTINCT] <result> [FROM <table-list>] | ||
1792 | [WHERE <expr>] | ||
1793 | [GROUP BY <expr-list>] | ||
1794 | [HAVING <expr>] | ||
1795 | [<compound-op> <select>]* | ||
1796 | [ORDER BY <sort-expr-list>] | ||
1797 | [LIMIT <integer> [LP OFFSET | , RP <integer>]] | ||
1798 | } {result} { | ||
1799 | <result-column> [, <result-column>]* | ||
1800 | } {result-column} { | ||
1801 | STAR | <table-name> . STAR | <expr> [ [AS] <string> ] | ||
1802 | } {table-list} { | ||
1803 | <table> [<join-op> <table> <join-args>]* | ||
1804 | } {table} { | ||
1805 | <table-name> [AS <alias>] | | ||
1806 | ( <select> ) [AS <alias>] | ||
1807 | } {join-op} { | ||
1808 | , | [NATURAL] [LEFT | RIGHT | FULL] [OUTER | INNER | CROSS] JOIN | ||
1809 | } {join-args} { | ||
1810 | [ON <expr>] [USING ( <id-list> )] | ||
1811 | } {sort-expr-list} { | ||
1812 | <expr> [<sort-order>] [, <expr> [<sort-order>]]* | ||
1813 | } {sort-order} { | ||
1814 | [ COLLATE <collation-name> ] [ ASC | DESC ] | ||
1815 | } {compound_op} { | ||
1816 | UNION | UNION ALL | INTERSECT | EXCEPT | ||
1817 | } | ||
1818 | |||
1819 | puts { | ||
1820 | <p>The SELECT statement is used to query the database. The | ||
1821 | result of a SELECT is zero or more rows of data where each row | ||
1822 | has a fixed number of columns. The number of columns in the | ||
1823 | result is specified by the expression list in between the | ||
1824 | SELECT and FROM keywords. Any arbitrary expression can be used | ||
1825 | as a result. If a result expression is } | ||
1826 | puts "[Operator *] then all columns of all tables are substituted" | ||
1827 | puts {for that one expression. If the expression is the name of} | ||
1828 | puts "a table followed by [Operator .*] then the result is all columns" | ||
1829 | puts {in that one table.</p> | ||
1830 | |||
1831 | <p>The DISTINCT keyword causes a subset of result rows to be returned, | ||
1832 | in which each result row is different. NULL values are not treated as | ||
1833 | distinct from each other. The default behavior is that all result rows | ||
1834 | be returned, which can be made explicit with the keyword ALL.</p> | ||
1835 | |||
1836 | <p>The query is executed against one or more tables specified after | ||
1837 | the FROM keyword. If multiple tables names are separated by commas, | ||
1838 | then the query is against the cross join of the various tables. | ||
1839 | The full SQL-92 join syntax can also be used to specify joins. | ||
1840 | A sub-query | ||
1841 | in parentheses may be substituted for any table name in the FROM clause. | ||
1842 | The entire FROM clause may be omitted, in which case the result is a | ||
1843 | single row consisting of the values of the expression list. | ||
1844 | </p> | ||
1845 | |||
1846 | <p>The WHERE clause can be used to limit the number of rows over | ||
1847 | which the query operates.</p> | ||
1848 | |||
1849 | <p>The GROUP BY clauses causes one or more rows of the result to | ||
1850 | be combined into a single row of output. This is especially useful | ||
1851 | when the result contains aggregate functions. The expressions in | ||
1852 | the GROUP BY clause do <em>not</em> have to be expressions that | ||
1853 | appear in the result. The HAVING clause is similar to WHERE except | ||
1854 | that HAVING applies after grouping has occurred. The HAVING expression | ||
1855 | may refer to values, even aggregate functions, that are not in the result.</p> | ||
1856 | |||
1857 | <p>The ORDER BY clause causes the output rows to be sorted. | ||
1858 | The argument to ORDER BY is a list of expressions that are used as the | ||
1859 | key for the sort. The expressions do not have to be part of the | ||
1860 | result for a simple SELECT, but in a compound SELECT each sort | ||
1861 | expression must exactly match one of the result columns. Each | ||
1862 | sort expression may be optionally followed by a COLLATE keyword and | ||
1863 | the name of a collating function used for ordering text and/or | ||
1864 | keywords ASC or DESC to specify the sort order.</p> | ||
1865 | |||
1866 | <p>The LIMIT clause places an upper bound on the number of rows | ||
1867 | returned in the result. A negative LIMIT indicates no upper bound. | ||
1868 | The optional OFFSET following LIMIT specifies how many | ||
1869 | rows to skip at the beginning of the result set. | ||
1870 | In a compound query, the LIMIT clause may only appear on the | ||
1871 | final SELECT statement. | ||
1872 | The limit is applied to the entire query not | ||
1873 | to the individual SELECT statement to which it is attached. | ||
1874 | Note that if the OFFSET keyword is used in the LIMIT clause, then the | ||
1875 | limit is the first number and the offset is the second number. If a | ||
1876 | comma is used instead of the OFFSET keyword, then the offset is the | ||
1877 | first number and the limit is the second number. This seeming | ||
1878 | contradition is intentional - it maximizes compatibility with legacy | ||
1879 | SQL database systems. | ||
1880 | </p> | ||
1881 | |||
1882 | <p>A compound SELECT is formed from two or more simple SELECTs connected | ||
1883 | by one of the operators UNION, UNION ALL, INTERSECT, or EXCEPT. In | ||
1884 | a compound SELECT, all the constituent SELECTs must specify the | ||
1885 | same number of result columns. There may be only a single ORDER BY | ||
1886 | clause at the end of the compound SELECT. The UNION and UNION ALL | ||
1887 | operators combine the results of the SELECTs to the right and left into | ||
1888 | a single big table. The difference is that in UNION all result rows | ||
1889 | are distinct where in UNION ALL there may be duplicates. | ||
1890 | The INTERSECT operator takes the intersection of the results of the | ||
1891 | left and right SELECTs. EXCEPT takes the result of left SELECT after | ||
1892 | removing the results of the right SELECT. When three or more SELECTs | ||
1893 | are connected into a compound, they group from left to right.</p> | ||
1894 | } | ||
1895 | |||
1896 | |||
1897 | Section UPDATE update | ||
1898 | |||
1899 | Syntax {sql-statement} { | ||
1900 | UPDATE [ OR <conflict-algorithm> ] [<database-name> .] <table-name> | ||
1901 | SET <assignment> [, <assignment>]* | ||
1902 | [WHERE <expr>] | ||
1903 | } {assignment} { | ||
1904 | <column-name> = <expr> | ||
1905 | } | ||
1906 | |||
1907 | puts { | ||
1908 | <p>The UPDATE statement is used to change the value of columns in | ||
1909 | selected rows of a table. Each assignment in an UPDATE specifies | ||
1910 | a column name to the left of the equals sign and an arbitrary expression | ||
1911 | to the right. The expressions may use the values of other columns. | ||
1912 | All expressions are evaluated before any assignments are made. | ||
1913 | A WHERE clause can be used to restrict which rows are updated.</p> | ||
1914 | |||
1915 | <p>The optional conflict-clause allows the specification of an alternative | ||
1916 | constraint conflict resolution algorithm to use during this one command. | ||
1917 | See the section titled | ||
1918 | <a href="#conflict">ON CONFLICT</a> for additional information.</p> | ||
1919 | } | ||
1920 | |||
1921 | |||
1922 | Section VACUUM vacuum | ||
1923 | |||
1924 | Syntax {sql-statement} { | ||
1925 | VACUUM [<index-or-table-name>] | ||
1926 | } | ||
1927 | |||
1928 | puts { | ||
1929 | <p>The VACUUM command is an SQLite extension modeled after a similar | ||
1930 | command found in PostgreSQL. If VACUUM is invoked with the name of a | ||
1931 | table or index then it is suppose to clean up the named table or index. | ||
1932 | In version 1.0 of SQLite, the VACUUM command would invoke | ||
1933 | <b>gdbm_reorganize()</b> to clean up the backend database file.</p> | ||
1934 | |||
1935 | <p> | ||
1936 | VACUUM became a no-op when the GDBM backend was removed from | ||
1937 | SQLITE in version 2.0.0. | ||
1938 | VACUUM was reimplemented in version 2.8.1. | ||
1939 | The index or table name argument is now ignored. | ||
1940 | </p> | ||
1941 | |||
1942 | <p>When an object (table, index, or trigger) is dropped from the | ||
1943 | database, it leaves behind empty space. This makes the database | ||
1944 | file larger than it needs to be, but can speed up inserts. In time | ||
1945 | inserts and deletes can leave the database file structure fragmented, | ||
1946 | which slows down disk access to the database contents. | ||
1947 | |||
1948 | The VACUUM command cleans | ||
1949 | the main database by copying its contents to a temporary database file and | ||
1950 | reloading the original database file from the copy. This eliminates | ||
1951 | free pages, aligns table data to be contiguous, and otherwise cleans | ||
1952 | up the database file structure.</p> | ||
1953 | |||
1954 | <p>The VACUUM command may change the | ||
1955 | <a href="lang_createtable.html#rowid">ROWID</a> of entires in tables that do | ||
1956 | not have an explicit INTEGER PRIMARY KEY.</p> | ||
1957 | |||
1958 | <p>VACUUM only works on the main database. | ||
1959 | It is not possible to VACUUM an attached database file.</p> | ||
1960 | |||
1961 | <p>The VACUUM command will fail if there is an active transaction. | ||
1962 | The VACUUM command is a no-op for in-memory databases.</p> | ||
1963 | |||
1964 | <p>As of SQLite version 3.1, an alternative to using the VACUUM command | ||
1965 | is auto-vacuum mode, enabled using the | ||
1966 | <a href="pragma.html#pragma_auto_vacuum">auto_vacuum pragma</a>. | ||
1967 | When auto-vacuum is enabled for a database, large deletes cause | ||
1968 | the size of the database file to shrink. However, auto-vacuum | ||
1969 | also causes excess fragmentation of the database file. And auto-vacuum | ||
1970 | does not compact partially filled pages of the database as VACUUM | ||
1971 | does. | ||
1972 | </p> | ||
1973 | } | ||
1974 | |||
1975 | # A list of keywords. A asterisk occurs after the keyword if it is on | ||
1976 | # the fallback list. | ||
1977 | # | ||
1978 | set keyword_list [lsort { | ||
1979 | ABORT* | ||
1980 | ADD | ||
1981 | AFTER* | ||
1982 | ALL | ||
1983 | ALTER | ||
1984 | ANALYZE* | ||
1985 | AND | ||
1986 | AS | ||
1987 | ASC* | ||
1988 | ATTACH* | ||
1989 | AUTOINCREMENT | ||
1990 | BEFORE* | ||
1991 | BEGIN* | ||
1992 | BETWEEN | ||
1993 | BY | ||
1994 | CASCADE* | ||
1995 | CASE | ||
1996 | CAST* | ||
1997 | CHECK | ||
1998 | COLLATE | ||
1999 | COMMIT | ||
2000 | CONFLICT* | ||
2001 | CONSTRAINT | ||
2002 | CREATE | ||
2003 | CROSS | ||
2004 | CURRENT_DATE* | ||
2005 | CURRENT_TIME* | ||
2006 | CURRENT_TIMESTAMP* | ||
2007 | DATABASE* | ||
2008 | DEFAULT | ||
2009 | DEFERRED* | ||
2010 | DEFERRABLE | ||
2011 | DELETE | ||
2012 | DESC* | ||
2013 | DETACH* | ||
2014 | DISTINCT | ||
2015 | DROP | ||
2016 | END* | ||
2017 | EACH* | ||
2018 | ELSE | ||
2019 | ESCAPE | ||
2020 | EXCEPT | ||
2021 | EXCLUSIVE* | ||
2022 | EXPLAIN* | ||
2023 | FAIL* | ||
2024 | FOR* | ||
2025 | FOREIGN | ||
2026 | FROM | ||
2027 | FULL | ||
2028 | GLOB* | ||
2029 | GROUP | ||
2030 | HAVING | ||
2031 | IF* | ||
2032 | IGNORE* | ||
2033 | IMMEDIATE* | ||
2034 | IN | ||
2035 | INDEX | ||
2036 | INITIALLY* | ||
2037 | INNER | ||
2038 | INSERT | ||
2039 | INSTEAD* | ||
2040 | INTERSECT | ||
2041 | INTO | ||
2042 | IS | ||
2043 | ISNULL | ||
2044 | JOIN | ||
2045 | KEY* | ||
2046 | LEFT | ||
2047 | LIKE* | ||
2048 | LIMIT | ||
2049 | MATCH* | ||
2050 | NATURAL | ||
2051 | NOT | ||
2052 | NOTNULL | ||
2053 | NULL | ||
2054 | OF* | ||
2055 | OFFSET* | ||
2056 | ON | ||
2057 | OR | ||
2058 | ORDER | ||
2059 | OUTER | ||
2060 | PLAN* | ||
2061 | PRAGMA* | ||
2062 | PRIMARY | ||
2063 | QUERY* | ||
2064 | RAISE* | ||
2065 | REFERENCES | ||
2066 | REINDEX* | ||
2067 | RENAME* | ||
2068 | REPLACE* | ||
2069 | RESTRICT* | ||
2070 | RIGHT | ||
2071 | ROLLBACK | ||
2072 | ROW* | ||
2073 | SELECT | ||
2074 | SET | ||
2075 | TABLE | ||
2076 | TEMP* | ||
2077 | TEMPORARY* | ||
2078 | THEN | ||
2079 | TO | ||
2080 | TRANSACTION | ||
2081 | TRIGGER* | ||
2082 | UNION | ||
2083 | UNIQUE | ||
2084 | UPDATE | ||
2085 | USING | ||
2086 | VACUUM* | ||
2087 | VALUES | ||
2088 | VIEW* | ||
2089 | VIRTUAL* | ||
2090 | WHEN | ||
2091 | WHERE | ||
2092 | }] | ||
2093 | |||
2094 | |||
2095 | |||
2096 | puts {<DIV class="pdf_section">} | ||
2097 | Section {SQLite Keywords} keywords | ||
2098 | puts {</DIV>} | ||
2099 | |||
2100 | puts { | ||
2101 | <p>The SQL standard specifies a huge number of keywords which may not | ||
2102 | be used as the names of tables, indices, columns, databases, user-defined | ||
2103 | functions, collations, virtual table modules, or any other named object. | ||
2104 | The list of keywords is so long that few people can remember them all. | ||
2105 | For most SQL code, your safest bet is to never use any English language | ||
2106 | word as the name of a user-defined object.</p> | ||
2107 | |||
2108 | <p>If you want to use a keyword as a name, you need to quote it. There | ||
2109 | are three ways of quoting keywords in SQLite:</p> | ||
2110 | |||
2111 | <p> | ||
2112 | <blockquote> | ||
2113 | <table class="pdf_functions"> | ||
2114 | <tr> <td valign="top"><b>'keyword'</b></td><td width="20"></td> | ||
2115 | <td>A keyword in single quotes is interpreted as a literal string | ||
2116 | if it occurs in a context where a string literal is allowed, otherwise | ||
2117 | it is understood as an identifier.</td></tr> | ||
2118 | <tr> <td valign="top"><b>"keyword"</b></td><td></td> | ||
2119 | <td>A keyword in double-quotes is interpreted as an identifier if | ||
2120 | it matches a known identifier. Otherwise it is interpreted as a | ||
2121 | string literal.</td></tr> | ||
2122 | <tr> <td valign="top"><b>[keyword]</b></td><td></td> | ||
2123 | <td>A keyword enclosed in square brackets is always understood as | ||
2124 | an identifier. This is not standard SQL. This quoting mechanism | ||
2125 | is used by MS Access and SQL Server and is included in SQLite for | ||
2126 | compatibility.</td></tr> | ||
2127 | </table> | ||
2128 | </blockquote> | ||
2129 | </p> | ||
2130 | |||
2131 | <p>Quoted keywords are unaesthetic. | ||
2132 | To help you avoid them, SQLite allows many keywords to be used unquoted | ||
2133 | as the names of databases, tables, indices, triggers, views, columns, | ||
2134 | user-defined functions, collations, attached databases, and virtual | ||
2135 | function modules. | ||
2136 | In the list of keywords that follows, those that can be used as identifiers | ||
2137 | are shown in an italic font. Keywords that must be quoted in order to be | ||
2138 | used as identifiers are shown in bold.</p> | ||
2139 | |||
2140 | <p> | ||
2141 | SQLite adds new keywords from time to time when it take on new features. | ||
2142 | So to prevent your code from being broken by future enhancements, you should | ||
2143 | normally quote any indentifier that is an English language word, even if | ||
2144 | you do not have to. | ||
2145 | </p> | ||
2146 | |||
2147 | <p> | ||
2148 | The following are the keywords currently recognized by SQLite: | ||
2149 | </p> | ||
2150 | |||
2151 | <blockquote> | ||
2152 | <table width="100%" class="pdf_keywords"> | ||
2153 | <tr> | ||
2154 | <td align="left" valign="top" width="20%"> | ||
2155 | } | ||
2156 | |||
2157 | set n [llength $keyword_list] | ||
2158 | set nCol 5 | ||
2159 | set nRow [expr {($n+$nCol-1)/$nCol}] | ||
2160 | set i 0 | ||
2161 | foreach word $keyword_list { | ||
2162 | if {[string index $word end]=="*"} { | ||
2163 | set word [string range $word 0 end-1] | ||
2164 | set font i | ||
2165 | } else { | ||
2166 | set font b | ||
2167 | } | ||
2168 | if {$i==$nRow} { | ||
2169 | puts "</td><td valign=\"top\" align=\"left\" width=\"20%\">" | ||
2170 | set i 1 | ||
2171 | } else { | ||
2172 | incr i | ||
2173 | } | ||
2174 | puts "<$font>$word</$font><br>" | ||
2175 | } | ||
2176 | |||
2177 | puts { | ||
2178 | </td></tr></table></blockquote> | ||
2179 | |||
2180 | <h2>Special names</h2> | ||
2181 | |||
2182 | <p>The following are not keywords in SQLite, but are used as names of | ||
2183 | system objects. They can be used as an identifier for a different | ||
2184 | type of object.</p> | ||
2185 | |||
2186 | <blockquote class="pdf_keywords"><b> | ||
2187 | _ROWID_<br> | ||
2188 | MAIN<br> | ||
2189 | OID<br> | ||
2190 | ROWID<br> | ||
2191 | SQLITE_MASTER<br> | ||
2192 | SQLITE_SEQUENCE<br> | ||
2193 | SQLITE_TEMP_MASTER<br> | ||
2194 | TEMP<br> | ||
2195 | </b></blockquote> | ||
2196 | } | ||
2197 | |||
2198 | puts {<DIV class="pdf_ignore">} | ||
2199 | footer $rcsid | ||
2200 | if {[string length $outputdir]} { | ||
2201 | footer $rcsid | ||
2202 | } | ||
2203 | puts {</DIV>} | ||