Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Add the observation that the unary "+" operator destroys type affinity. |
|---|---|
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: |
b46eae7d62daf51e84abd8fe1361623f |
| User & Date: | drh 2008-09-22 12:42:19 |
Context
|
2008-09-23
| ||
| 18:06 | Add some more to fileio.html. check-in: 3a3fd02722 user: dan tags: trunk | |
|
2008-09-22
| ||
| 12:42 | Add the observation that the unary "+" operator destroys type affinity. check-in: b46eae7d62 user: drh tags: trunk | |
|
2008-09-18
| ||
| 15:22 | Documentation updates for version 3.6.3. check-in: 49535dba2b user: drh tags: trunk | |
Changes
Changes to pages/faq.in.
80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 |
<p>But SQLite does use the declared type of a column as a hint
that you prefer values in that format. So, for example, if a
column is of type INTEGER and you try to insert a string into
that column, SQLite will attempt to convert the string into an
integer. If it can, it inserts the integer instead. If not,
it inserts the string. This feature is sometimes
call <a href="datatype3.html#affinity">type affinity</a>.
</p>
}
faq {
Why doesn't SQLite allow me to use '0' and '0.0' as the primary
key on two different rows of the same table?
} {
|
| |
80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 |
<p>But SQLite does use the declared type of a column as a hint
that you prefer values in that format. So, for example, if a
column is of type INTEGER and you try to insert a string into
that column, SQLite will attempt to convert the string into an
integer. If it can, it inserts the integer instead. If not,
it inserts the string. This feature is sometimes
called <a href="datatype3.html#affinity">type affinity</a>.
</p>
}
faq {
Why doesn't SQLite allow me to use '0' and '0.0' as the primary
key on two different rows of the same table?
} {
|
Changes to pages/optoverview.in.
387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 |
But it will prevent the term from constraining an index.
So, in the example above, if the query were rewritten as:
}
CODE {
SELECT z FROM ex2 WHERE +x=5 AND y=6;
}
PARAGRAPH {
The *+* operator on the *x* column would prevent that term from
constraining an index. This would force the use of the ex2i2 index.
}
HEADING 1 {Avoidance of table lookups} index_only
PARAGRAPH {
When doing an indexed lookup of a row, the usual procedure is to
do a binary search on the index to find the index entry, then extract
the rowid from the index and use that rowid to do a binary search on
|
| > > > > > > > > > > > |
387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 |
But it will prevent the term from constraining an index.
So, in the example above, if the query were rewritten as:
}
CODE {
SELECT z FROM ex2 WHERE +x=5 AND y=6;
}
PARAGRAPH {
The *+* operator on the *x* column will prevent that term from
constraining an index. This would force the use of the ex2i2 index.
}
PARAGRAPH {
Note that the unary *+* operator also removes
<a href="datatype3.html#affinity">type affinity</a> from
an expression, and in some cases this can cause subtle changes in
the meaning of an expression.
In the example above,
if column *x* has <a href="datatype3.html#affinity">TEXT affinity</a>
then the comparison "x=5" will be done as text. But the *+* operator
removes the affinity. So the comparison "+x=5" will compare the text
in column *x* with the numeric value 5 and will always be false.
}
HEADING 1 {Avoidance of table lookups} index_only
PARAGRAPH {
When doing an indexed lookup of a row, the usual procedure is to
do a binary search on the index to find the index entry, then extract
the rowid from the index and use that rowid to do a binary search on
|