Documentation Source Text

Check-in [b46eae7d62]
Login

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: b46eae7d62daf51e84abd8fe1361623f48bbfdd8
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
Hide Diffs Unified Diffs Ignore Whitespace Patch

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