Documentation Source Text

Check-in [ab0a116d70]
Login

Many hyperlinks are disabled.
Use anonymous login to enable hyperlinks.

Overview
Comment:Typo fix.
Downloads: Tarball | ZIP archive
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: ab0a116d70c11ba65f63c9b1b9d96819a49ac37e
User & Date: drh 2016-02-17 04:59:42.172
Context
2016-03-03
16:07
Changes for the 3.11.1 release. (check-in: 628be086c5 user: drh tags: branch-3.11)
2016-02-17
16:14
Fix the PRAGMA synchorous documentation. The default is always FULL even in WAL mode. (check-in: 3540d671bc user: drh tags: trunk)
04:59
Typo fix. (check-in: ab0a116d70 user: drh tags: trunk)
2016-02-15
18:26
Separate heading for hashes in the 3.11.0 change log. (check-in: b04e9be1a4 user: drh tags: trunk)
Changes
Unified Diff Ignore Whitespace Patch
Changes to pages/datatypes.in.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<title>Datatypes In SQLite version 2</title>

<h2>Datatypes In SQLite Version 2</h2>

<h3>1.0 &nbsp; Typelessness</h3>
<p>
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.











|







1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<title>Datatypes In SQLite version 2</title>

<h2>Datatypes In SQLite Version 2</h2>

<h3>1.0 &nbsp; Typelessness</h3>
<p>
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 supposed 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.