https://www.sqlite.org/draft/stricttables.html
SQLite
*** DRAFT ***
* Home
* Menu
* About
* Documentation
* Download
* License
* Support
* Purchase
* Search
* About
* Documentation
* Download
* Support
* Purchase
[Search Documentation] [ ] [Go]
STRICT Tables
1. Introduction
SQLite strives to be flexible regarding the datatype of the content
that it stores. For example, if a table column as 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
Datatypes In SQLite document for additional information.
Many developers appreciate the flexible typing rules of SQLite and
use them 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 circa pending) that is enabled separately for each
table.
1.1. STRICT Tables
In a CREATE TABLE statement, if the "STRICT" table-option keyword is
added to the end, after the closing ")", then strict typing rules
apply to that table. This means:
1. Every column must have a datatype. The freedom to specify a
column without a datatype is removed.
2. The datatype must be one of:
+ INT
+ INTEGER
+ REAL
+ TEXT
+ BLOB
3. Content inserted into the column 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, just as
PostgreSQL does, but if the value cannot be losslessly converted
in the specified datatype, then an SQLITE_CONSTRAINT_DATATYPE
error is raised.
4. Columns that are part of the PRIMARY KEY must be NOT NULL.
*** DRAFT ***