Many hyperlinks are disabled.
Use anonymous login
to enable hyperlinks.
Overview
| Comment: | Pickup the 'vtab.html' doc fix from upstream. |
|---|---|
| Downloads: | Tarball | ZIP archive | SQL archive |
| Timelines: | family | ancestors | descendants | both | trunk |
| Files: | files | file ages | folders |
| SHA1: |
006a35fb5e2a258451c0df653aa2795b |
| User & Date: | mistachkin 2016-08-09 00:20:07 |
Context
|
2016-08-25
| ||
| 01:14 | Add a couple more 'successful' exit codes for the Microsoft Visual C++ Redistributable for Visual Studio. Pursuant to [86d8e9b4d0]. check-in: 33a2920cbe user: mistachkin tags: trunk | |
|
2016-08-09
| ||
| 00:20 | Pickup the 'vtab.html' doc fix from upstream. check-in: 006a35fb5e user: mistachkin tags: trunk | |
| 00:02 | Pickup the SQLite core library 3.14 doc changes from upstream. check-in: 70455e449b user: mistachkin tags: trunk | |
Changes
Changes to Doc/Special/Core/vtab.html.
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
...
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
|
or in a USING or ON clause that is of the form
<blockquote>
column OP EXPR
</blockquote>
<p>Where "column" is a column in the virtual table, OP is an operator
like "=" or "<", and EXPR is an arbitrary expression. So, for example,
if the WHERE clause contained a term like this:
<blockquote><pre>
a = 5
</pre></blockquote>
<p>Then one of the constraints would be on the "a" column with
................................................................................
literal representation of the WHERE clause. The query optimizer might
make transformations to the
WHERE clause in order to extract as many constraints
as it can. So, for example, if the WHERE clause contained something
like this:
<blockquote><pre>
x BETWEEN 10 AND 100 AND 999>y
</pre></blockquote>
<p>The query optimizer might translate this into three separate constraints:
<blockquote><pre>
x >= 10
x <= 100
y < 999
</pre></blockquote>
<p>For each constraint, the aConstraint[].iColumn field indicates which
column appears on the left-hand side of the constraint.
The first column of the virtual table is column 0.
The rowid of the virtual table is column -1.
The aConstraint[].op field indicates which operator is used.
|
|
|
|
|
|
|
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
...
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
|
or in a USING or ON clause that is of the form
<blockquote>
column OP EXPR
</blockquote>
<p>Where "column" is a column in the virtual table, OP is an operator
like "=" or "<", and EXPR is an arbitrary expression. So, for example,
if the WHERE clause contained a term like this:
<blockquote><pre>
a = 5
</pre></blockquote>
<p>Then one of the constraints would be on the "a" column with
................................................................................
literal representation of the WHERE clause. The query optimizer might
make transformations to the
WHERE clause in order to extract as many constraints
as it can. So, for example, if the WHERE clause contained something
like this:
<blockquote><pre>
x BETWEEN 10 AND 100 AND 999>y
</pre></blockquote>
<p>The query optimizer might translate this into three separate constraints:
<blockquote><pre>
x >= 10
x <= 100
y < 999
</pre></blockquote>
<p>For each constraint, the aConstraint[].iColumn field indicates which
column appears on the left-hand side of the constraint.
The first column of the virtual table is column 0.
The rowid of the virtual table is column -1.
The aConstraint[].op field indicates which operator is used.
|