Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
Comment: | Add the observation that the unary "+" operator destroys type affinity. |
---|---|
Downloads: | Tarball | ZIP archive |
Timelines: | family | ancestors | descendants | both | trunk |
Files: | files | file ages | folders |
SHA1: |
b46eae7d62daf51e84abd8fe1361623f |
User & Date: | drh 2008-09-22 12:42:19.000 |
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 | <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 | | | 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 | 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 { | | > > > > > > > > > > > | 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 |
︙ | ︙ |