+Back to the SQLite Home Page
++(This page was last modified on [lrange $rcsid 3 4] UTC) +
" + +puts {+SQLite is "typeless". This means that you can store any +kind of data you want in any column of any table, regardless of the +declared datatype of that column. +(See the one exception to this rule in section 2.0 below.) +This behavior is a feature, not +a bug. A database is suppose to store and retrieve data and it +should not matter to the database what format that data is in. +The strong typing system found in most other SQL engines and +codified in the SQL language spec is a misfeature - +it is an example of the implementation showing through into the +interface. SQLite seeks to overcome this misfeature by allowing +you to store any kind of data into any kind of column and by +allowing flexibility in the specification of datatypes. +
+ ++A datatype to SQLite is any sequence of zero or more names +optionally followed by a parenthesized lists of one or two +signed integers. Notice in particular that a datatype may +be zero or more names. That means that an empty +string is a valid datatype as far as SQLite is concerned. +So you can declare tables where the datatype of each column +is left unspecified, like this: +
+ ++ ++CREATE TABLE ex1(a,b,c); +
+Even though SQLite allows the datatype to be omitted, it is +still a good idea to include it in your CREATE TABLE statements, +since the data type often serves as a good hint to other +programmers about what you intend to put in the column. And +if you ever port your code to another database engine, that +other engine will probably require a datatype of some kind. +SQLite accepts all the usual datatypes. For example: +
+ ++ ++CREATE TABLE ex2( + a VARCHAR(10), + b NVARCHAR(15), + c TEXT, + d INTEGER, + e FLOAT, + f BOOLEAN, + g CLOB, + h BLOB, + i TIMESTAMP, + j NUMERIC(10,5) + k VARYING CHARACTER (24), + l NATIVE VARYING CHAR(16) +); +
+And so forth. Basically any sequence of names optionally followed by +one or two signed integers in parentheses will do. +
+ ++One exception to the typelessness of SQLite is a column whose type +is INTEGER PRIMARY KEY. (And you must use "INTEGER" not "INT". +A column of type INT PRIMARY KEY is typeless just like any other.) +INTEGER PRIMARY KEY columns must contain a 32-bit signed integer. Any +attempt to insert non-integer data will result in an error. +
+ ++INTEGER PRIMARY KEY columns can be used to implement the equivalent +of AUTOINCREMENT. If you try to insert a NULL into an INTEGER PRIMARY +KEY column, the column will actually be filled with a integer that is +one greater than the largest key already in the table. Or if the +largest key is 2147483647, then the column will be filled with a +random integer. Either way, the INTEGER PRIMARY KEY column will be +assigned a unique integer. You can retrieve this integer using +the sqlite_last_insert_rowid() API function or using the +last_insert_rowid() SQL function is a subsequent SELECT statement. +
+ ++SQLite is typeless for the purpose of deciding what data is allowed +to be stored in a column. But some notion of type comes into play +when sorting and comparing data. For these purposes, a column or +an expression can be one of two types: numeric and text. +The sort or comparison may give different results depending on which +type of data is being sorted or compared. +
+ ++If data is of type text then the comparison is determined by +the standard C data comparison functions memcmp() or +strcmp(). The comparison looks at bytes from two inputs one +by one and returns the first non-zero difference. +String are '\000' terminated so shorter +strings sort before longer strings, as you would expect. +
+ ++For numeric data, this situation is more complex. If both strings +being compared look like well-formed numbers, then they are converted +into floating point values using atof() and compared numerically. +If one input is not a well-formed number but the other is, then the +number is considered to be less than the non-number. If neither inputs +is a well-formed number, then strcmp() is used to do the +comparison. +
+ ++Do not be confused by the fact that a column might have a "numeric" +datatype. This does not mean that the column can contain only numbers. +It merely means that if the column does contain a number, that number +will sort in numerical order. +
+ ++For both text and numeric values, NULL sorts before any other value. +A comparison of any value against NULL using operators like "<" or +">=" is always false. +
+ ++For SQLite version 2.6.3 and earlier, all values used the numeric datatype. +The text datatype appears in version 2.7.0 and later. In the sequel it +is assumed that you are using version 2.7.0 or later of SQLite. +
+ ++For an expression, the datatype of the result is often determined by +the outermost operator. For example, arithmatic operators ("+", "*", "%") +always return a numeric results. The string concatenation operator +("||") returns a text result. And so forth. If you are ever in doubt +about the datatype of an expression you can use the special typeof() +SQL function to determine what the datatype is. For example: +
+ +
+sqlite> SELECT typeof('abc'+123);
+numeric
+sqlite> SELECT typeof('abc'||123);
+text
++For table columns, the datatype is determined by the datatype declaration +of the CREATE TABLE statement. The datatype is text if and only if +the type declaration contains one or more of the following strings: +
+ ++BLOB+ +
+CHAR
+CLOB +TEXT +
+The search for these strings in the type declaration is case insensitive, +of course. If any of the above strings occur anywhere in the type +declaration, then the datatype of the column is text. Otherwise the +datatype is numeric. Note in particular that the datatype for columns +with an empty type declaration is numeric. +
+} + +puts { +
+Back to the SQLite Home Page
+
Each column definition is the name of the column followed by the datatype for that column, then one or more optional column constraints. -The datatype for the column is (usually) ignored and may be omitted. +SQLite is typeless. +The datatype for the column does not constraint what data may be put +in that column. All information is stored as null-terminated strings. The UNIQUE constraint causes an index to be created on the specified columns. This index must contain unique keys. diff --git a/www/omitted.tcl b/www/omitted.tcl new file mode 100644 index 0000000000..e14b94bcf6 --- /dev/null +++ b/www/omitted.tcl @@ -0,0 +1,91 @@ +# +# Run this script to generated a omitted.html output file +# +set rcsid {$Id: omitted.tcl,v 1.1 2002/08/14 00:08:14 drh Exp $} + +puts { +
++(This page was last modified on [lrange $rcsid 3 4] UTC) +
" + +puts { ++Rather than try to list all the features of SQL92 that SQLite does +support, it is much easier to list those that it does not. +The following are features of of SQL92 that SQLite does not implement. +
+ +| $desc |
+If you find other SQL92 features that SQLite does not support, please +send e-mail to drh@hwaci.com so they +can be added to this list. +
+