Documentation Source Text

Check-in [a85aaa0b62]
Login

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

Overview
Comment:Fix typos reported on the mailing list.
Timelines: family | ancestors | descendants | both | trunk
Files: files | file ages | folders
SHA1: a85aaa0b623a59a3976d01d4a1e667060f303a5d
User & Date: drh 2010-08-10 05:58:55
Context
2010-08-12
14:38
Update the file format documentation for the new 64K page size. Add a caution to the WAL document. Omit annoying echos in the script that removes requirement marks from the documentation. check-in: 0ec9f2cb8f user: drh tags: trunk
2010-08-10
05:58
Fix typos reported on the mailing list. check-in: a85aaa0b62 user: drh tags: trunk
2010-08-09
15:45
Fix a bunch of documentation typos reported on the mailing list. check-in: d9e242f92a user: drh tags: trunk
Changes
Hide Diffs Unified Diffs Ignore Whitespace Patch

Changes to pages/version3.in.

104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
...
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182

<p>
SQLite version 2.8 had the feature that any type of data could be stored
in any table column regardless of the declared type of that column.  This
feature is retained in version 3.0, though in a slightly modified form.
Each table column will store any type of data, though columns have an
affinity for the format of data defined by their declared datatype.
When data is inserted into a column, that column will make at attempt
to convert the data format into the columns declared type.   All SQL
database engines do this.  The difference is that SQLite 3.0 will 
still store the data even if a format conversion is not possible.
</p>

<p>
For example, if you have a table column declared to be of type "INTEGER"
and you try to insert a string, the column will look at the text string
................................................................................
with UTF-8 text.  So if you supply UTF-16 text it will be converted.
This is just an implementation issue and there is nothing to prevent
future versions of SQLite from parsing UTF-16 encoded SQL natively.
</p>

<p>
When creating new user-defined SQL functions and collating sequences,
each function or collating sequence can specify it if works with
UTF-8, UTF-16be, or UTF-16le.  Separate implementations can be registered
for each encoding.   If an SQL function or collating sequences is required
but a version for the current text encoding is not available, then 
the text is automatically converted.  As before, this conversion takes
computation time, so programmers are advised to pick a single
encoding and stick with it in order to minimize the amount of unnecessary
format juggling.
</p>








|
|







 







|

|







104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
...
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182

<p>
SQLite version 2.8 had the feature that any type of data could be stored
in any table column regardless of the declared type of that column.  This
feature is retained in version 3.0, though in a slightly modified form.
Each table column will store any type of data, though columns have an
affinity for the format of data defined by their declared datatype.
When data is inserted into a column, that column will make an attempt
to convert the data format into the column's declared type.   All SQL
database engines do this.  The difference is that SQLite 3.0 will 
still store the data even if a format conversion is not possible.
</p>

<p>
For example, if you have a table column declared to be of type "INTEGER"
and you try to insert a string, the column will look at the text string
................................................................................
with UTF-8 text.  So if you supply UTF-16 text it will be converted.
This is just an implementation issue and there is nothing to prevent
future versions of SQLite from parsing UTF-16 encoded SQL natively.
</p>

<p>
When creating new user-defined SQL functions and collating sequences,
each function or collating sequence can specify if it works with
UTF-8, UTF-16be, or UTF-16le.  Separate implementations can be registered
for each encoding.   If an SQL function or collating sequence is required
but a version for the current text encoding is not available, then 
the text is automatically converted.  As before, this conversion takes
computation time, so programmers are advised to pick a single
encoding and stick with it in order to minimize the amount of unnecessary
format juggling.
</p>