System.Data.SQLite
Check-in [006a35fb5e]
Not logged in

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: 006a35fb5e2a258451c0df653aa2795b64d38588
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
Hide Diffs Unified Diffs Show Whitespace Changes Patch

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 "&lt;", 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&gt;y
</pre></blockquote>

<p>The query optimizer might translate this into three separate constraints:

<blockquote><pre>
     x &gt;= 10
     x &lt;= 100
     y &lt; 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.