1 files changed, 320 insertions, 0 deletions
diff --git a/www/stricttables.html b/www/stricttables.html
new file mode 100644
index 0000000..e1f670f
--- /dev/null
+++ b/www/stricttables.html
@@ -0,0 +1,320 @@
+<!DOCTYPE html>
+<html><head>
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<meta http-equiv="content-type" content="text/html; charset=UTF-8">
+<link href="sqlite.css" rel="stylesheet">
+<title>STRICT Tables</title>
+<!-- path= -->
+</head>
+<body>
+<div class=nosearch>
+<a href="index.html">
+<img class="logo" src="images/sqlite370_banner.gif" alt="SQLite" border="0">
+</a>
+<div><!-- IE hack to prevent disappearing logo --></div>
+<div class="tagline desktoponly">
+Small. Fast. Reliable.<br>Choose any three.
+</div>
+<div class="menu mainmenu">
+<ul>
+<li><a href="index.html">Home</a>
+<li class='mobileonly'><a href="javascript:void(0)" onclick='toggle_div("submenu")'>Menu</a>
+<li class='wideonly'><a href='about.html'>About</a>
+<li class='desktoponly'><a href="docs.html">Documentation</a>
+<li class='desktoponly'><a href="download.html">Download</a>
+<li class='wideonly'><a href='copyright.html'>License</a>
+<li class='desktoponly'><a href="support.html">Support</a>
+<li class='desktoponly'><a href="prosupport.html">Purchase</a>
+<li class='search' id='search_menubutton'>
+<a href="javascript:void(0)" onclick='toggle_search()'>Search</a>
+</ul>
+</div>
+<div class="menu submenu" id="submenu">
+<ul>
+<li><a href='about.html'>About</a>
+<li><a href='docs.html'>Documentation</a>
+<li><a href='download.html'>Download</a>
+<li><a href='support.html'>Support</a>
+<li><a href='prosupport.html'>Purchase</a>
+</ul>
+</div>
+<div class="searchmenu" id="searchmenu">
+<form method="GET" action="search">
+<select name="s" id="searchtype">
+<option value="d">Search Documentation</option>
+<option value="c">Search Changelog</option>
+</select>
+<input type="text" name="q" id="searchbox" value="">
+<input type="submit" value="Go">
+</form>
+</div>
+</div>
+<script>
+function toggle_div(nm) {
+var w = document.getElementById(nm);
+if( w.style.display=="block" ){
+w.style.display = "none";
+}else{
+w.style.display = "block";
+}
+}
+function toggle_search() {
+var w = document.getElementById("searchmenu");
+if( w.style.display=="block" ){
+w.style.display = "none";
+} else {
+w.style.display = "block";
+setTimeout(function(){
+document.getElementById("searchbox").focus()
+}, 30);
+}
+}
+function div_off(nm){document.getElementById(nm).style.display="none";}
+window.onbeforeunload = function(e){div_off("submenu");}
+/* Disable the Search feature if we are not operating from CGI, since */
+/* Search is accomplished using CGI and will not work without it. */
+if( !location.origin || !location.origin.match || !location.origin.match(/http/) ){
+document.getElementById("search_menubutton").style.display = "none";
+}
+/* Used by the Hide/Show button beside syntax diagrams, to toggle the */
+function hideorshow(btn,obj){
+var x = document.getElementById(obj);
+var b = document.getElementById(btn);
+if( x.style.display!='none' ){
+x.style.display = 'none';
+b.innerHTML='show';
+}else{
+x.style.display = '';
+b.innerHTML='hide';
+}
+return false;
+}
+var antiRobot = 0;
+function antiRobotGo(){
+if( antiRobot!=3 ) return;
+antiRobot = 7;
+var j = document.getElementById("mtimelink");
+if(j && j.hasAttribute("data-href")) j.href=j.getAttribute("data-href");
+}
+function antiRobotDefense(){
+document.body.onmousedown=function(){
+antiRobot |= 2;
+antiRobotGo();
+document.body.onmousedown=null;
+}
+document.body.onmousemove=function(){
+antiRobot |= 2;
+antiRobotGo();
+document.body.onmousemove=null;
+}
+setTimeout(function(){
+antiRobot |= 1;
+antiRobotGo();
+}, 100)
+antiRobotGo();
+}
+antiRobotDefense();
+</script>
+<div class=fancy>
+<div class=nosearch>
+<div class="fancy_title">
+STRICT Tables
+</div>
+</div>
+
+
+
+
+<h1 id="introduction"><span>1. </span>Introduction</h1>
+
+<p>SQLite strives to be flexible regarding the datatype of
+the content that it stores.  For example, if a table column has a type of
+"INTEGER", then SQLite tries to convert anything inserted into that column
+into an integer.  So an attempt to insert the string '123' results
+in an integer 123 being inserted.  But if the content cannot be losslessly
+converted into an integer, for example if the input is 'xyz', then
+the original string is inserted instead.
+See the <a href="datatype3.html">Datatypes In SQLite</a> document for additional information.
+
+</p><p>Some developers <a href="flextypegood.html">appreciate the freedom</a> that SQLite's flexible typing
+rules provide and use that freedom to advantage.
+But other developers are aghast at SQLite's
+flagrant rule-breaking and prefer the traditional rigid type
+system found in all other SQL database engines and in the
+SQL standard.  For this latter group, SQLite supports a strict typing
+mode, as of version 3.37.0 (2021-11-27), that is enabled
+separately for each table.
+
+</p><h1 id="strict_tables"><span>2. </span>STRICT Tables</h1>
+
+<p>In a <a href="lang_createtable.html">CREATE TABLE</a> statement, if the "STRICT" table-option keyword is
+added to the end, after the closing ")", then strict typing rules apply
+to that table. 
+The STRICT keyword causes the following differences:
+
+</p><ol>
+<li><p>
+Every column definition must specify a datatype for that column.
+The freedom to specify a column without a datatype is removed.
+
+</p></li><li><p>
+The datatype must be one of following:
+</p><ul>
+<li> INT
+</li><li> INTEGER
+</li><li> REAL
+</li><li> TEXT
+</li><li> BLOB
+</li><li> ANY
+</li></ul>
+<p>No other datatype names are allowed, though new types might be added in
+future releases of SQLite.
+
+</p></li><li><p>
+Content inserted into the column with a datatype other than ANY
+must be either a NULL (assuming there
+is no NOT NULL constraint on the column) or the type specified.
+SQLite attempts to coerce the data into the appropriate type using the usual
+affinity rules, as PostgreSQL, MySQL, SQL Server,
+and Oracle all do.  If the value cannot be
+losslessly converted in the specified datatype, then an
+SQLITE_CONSTRAINT_DATATYPE error is raised.
+
+</p></li><li><p>
+Columns with datatype ANY can accept any kind of data (except they will
+reject NULL values if they have a NOT NULL constraint, of course).  No
+type coercion occurs for a column of type ANY in a STRICT table.
+
+</p></li><li><p>
+Columns that are part of the PRIMARY KEY are implicitly NOT NULL.
+However, even though the PRIMARY KEY has an implicit NOT NULL constraint,
+when a NULL value is inserted into an <a href="lang_createtable.html#rowid">INTEGER PRIMARY KEY</a> column, the
+NULL is automatically converted into a unique integer, using the same
+rules for <a href="lang_createtable.html#rowid">INTEGER PRIMARY KEY</a> on ordinary, non-strict tables.
+
+</p></li><li><p>
+The <a href="pragma.html#pragma_integrity_check">PRAGMA integrity_check</a> and <a href="pragma.html#pragma_quick_check">PRAGMA quick_check</a> commands check the
+type of the content of all columns in STRICT tables and show errors if
+anything is amiss.
+</p></li></ol>
+
+<p>
+Everything else about a STRICT table works the same as it does in an
+ordinary non-strict table:
+
+</p><ul>
+<li> <a href="lang_createtable.html#ckconst">CHECK constraints</a> work the same.
+</li><li> <a href="lang_createtable.html#notnullconst">NOT NULL constraints</a> work the same.
+</li><li> <a href="foreignkeys.html">FOREIGN KEY constraints</a> work the same.
+</li><li> <a href="lang_createtable.html#uniqueconst">UNIQUE constraints</a> work the same.
+</li><li> <a href="lang_createtable.html#dfltval">DEFAULT clauses</a> work the same.
+</li><li> <a href="lang_createtable.html#collateclause">COLLATE clauses</a> work the same.
+</li><li> <a href="gencol.html">Generated columns</a> work the same.
+</li><li> <a href="lang_conflict.html">ON CONFLICT clauses</a> work the same.
+</li><li> <a href="lang_createindex.html">Indexes</a> work the same.
+</li><li> <a href="autoinc.html">AUTOINCREMENT</a> works the same.
+</li><li> An <a href="lang_createtable.html#rowid">INTEGER PRIMARY KEY</a> column is an alias for the <a href="lang_createtable.html#rowid">rowid</a>, but an
+INT PRIMARY KEY column is not.
+</li><li> The <a href="fileformat2.html">on-disk format</a> for the <a href="fileformat2.html##sqltab">table data</a> is the same.
+</li></ul>
+
+<h1 id="the_any_datatype"><span>3. </span>The ANY datatype</h1>
+
+<p>The ability to host any type of data in a single column has proven to
+be remarkably useful over the years.  In order to continue supporting this
+ability, even in STRICT tables, the new ANY datatype name is introduced.
+When the datatype of a column is "ANY", that means that any kind of data - 
+integers, floating point values, strings, or binary blobs, can be inserted
+into that table and its value and datatype will be preserved exactly as
+it is inserted.  As far as we know, SQLite is the only SQL database engine
+that supports this advanced capability.
+
+</p><p>The behavior of ANY is slightly different in a
+STRICT table versus an ordinary non-strict table.  In a STRICT table,
+a column of type ANY always preserves the data exactly as it is received.
+For an ordinary non-strict table, a column of type ANY will attempt to
+convert strings that look like numbers into a numeric value, and if
+successful will store the numeric value rather than the original string.
+For example:
+
+</p><center>
+<table border="1">
+<tr><th>STRICT</th><th>ordinary non-strict
+</th></tr><tr><td><pre>CREATE TABLE t1(a ANY) STRICT;
+INSERT INTO t1 VALUES('000123');
+SELECT typeof(a), quote(a) FROM t1;
+-- result: text '000123'</pre>
+</td><td><pre>
+CREATE TABLE t1(a ANY);
+INSERT INTO t1 VALUES('000123');
+SELECT typeof(a), quote(a) FROM t1;
+-- result: integer 123</pre>
+</td></tr></table>
+</center>
+
+<h1 id="backwards_compatibility"><span>4. </span>Backwards Compatibility</h1>
+
+<p>The STRICT keyword at the end of a CREATE TABLE statement is only
+recognized by SQLite version 3.37.0 (2021-11-27) and later.  If
+you try to open a database containing the STRICT keyword in an earlier
+version of SQLite, it will not recognize the keyword and will report
+an error (except as noted below).  But apart from the extra STRICT keyword,
+the underlying <a href="fileformat2.html">file format</a> of the database is identical.
+
+</p><p>Thus, in general, a database file that contains one or more STRICT
+tables can only be read and written by SQLite version 3.37.0 or later.
+However, a database created by SQLite 3.37.0 or later can still be
+read and written by earlier versions of SQLite, going all the way back
+to version 3.0.0 (2004-06-18) as long as the database does not contain
+any STRICT tables or other features that were introduced after the older
+version of SQLite.
+
+</p><p>The STRICT keyword may still be used as an identifier.
+(It is only treated as a keyword in a certain part of the syntax,
+and sqlite3_keyword_check(..) does not recognize it as a regular keyword.)
+
+</p><h2 id="accessing_strict_tables_in_earlier_versions_of_sqlite"><span>4.1. </span>Accessing STRICT tables in earlier versions of SQLite</h2>
+
+<p>Because of a quirk in the SQL language parser, versions of SQLite prior
+to 3.37.0 can still read and write STRICT tables if they set
+"<a href="pragma.html#pragma_writable_schema">PRAGMA writable_schema=ON</a>" immediately after opening the database
+file, prior to doing anything else that requires knowing the schema.
+One of the features of PRAGMA writable_schema=ON is that it disables
+errors in the schema parser.  This is intentional, because a big reason for
+having PRAGMA writable_schema=ON is to facilitate recovery of database files
+with corrupt schemas.  So with writable_schema=ON, when the schema
+parser reaches the STRICT keyword, it says to itself "I don't know what
+to do with this, but everything up to this point seems like a valid
+table definition so I'll just use what I have."  Hence, the STRICT
+keyword is effectively ignored.  Because nothing else about the file
+format changes for STRICT tables, everything else will work normally.
+Of course, rigid type enforcement will not occur because the earlier
+versions of SQLite do not know how to do that.
+
+</p><p>The <a href="cli.html#dump">.dump</a> command in the <a href="cli.html">CLI</a> sets <a href="pragma.html#pragma_writable_schema">PRAGMA writable_schema=ON</a>, because
+.dump is designed to extract as much content as it can even from a corrupt
+database file.  Hence, if you are using an older version of SQLite and
+you open a database with STRICT tables in the CLI and issue the ".dump"
+command before doing anything else, you will be able to read and write
+to the STRICT tables without rigid type enforcement.  This could, potentially,
+corrupt the database, by allowing incorrect types into STRICT tables.
+Reopening the database with a newer version of SQLite and running
+"<a href="pragma.html#pragma_quick_check">PRAGMA quick_check</a>" will detect and report all such corruption.
+
+</p><h1 id="other_table_options"><span>5. </span>Other Table Options</h1>
+
+<p>The SQLite parser accepts a comma-separated list of table options after
+the final close parenthesis in a CREATE TABLE statement.  As of this
+writing (2021-08-23) only two options are recognized:
+
+</p><ul>
+<li> STRICT
+</li><li> <a href="withoutrowid.html">WITHOUT ROWID</a>
+</li></ul>
+
+<p>If there are multiple options, they can be specified in any order.
+To keep things simple, the current parser accepts duplicate options without
+complaining, but that might change in future releases, so applications
+should not rely on it.
+</p><p align="center"><small><i>This page last modified on  <a href="https://sqlite.org/docsrc/honeypot" id="mtimelink"  data-href="https://sqlite.org/docsrc/finfo/pages/stricttables.in?m=8e4caa36c05200047">2022-01-20 21:38:08</a> UTC </small></i></p>
+