Further refinement of the in-operator.md documentation.

FossilOrigin-Name: df0648373a50006ca18d692e12552d1d53d549e3

manifest

@@ -1,5 +1,5 @@
-C Improvements\sto\sIN\soperator\scode\sgenerator\scomments.\s\sAvoid\sunnecessary\nCopy\soperations\son\sthe\sLHS\sof\sthe\sIN\soperator.
-D 2016-08-25T15:46:25.026
+C Further\srefinement\sof\sthe\sin-operator.md\sdocumentation.
+D 2016-08-25T17:40:32.626
 F Makefile.in cfd8fb987cd7a6af046daa87daa146d5aad0e088
 F Makefile.linux-gcc 7bc79876b875010e8c8f9502eb935ca92aa3c434
 F Makefile.msc d66d0395c38571aab3804f8db0fa20707ae4609a
@@ -346,7 +346,7 @@ F src/global.c c45ea22aff29334f6a9ec549235ac3357c970015
 F src/hash.c 55b5fb474100cee0b901edaf203e26c970940f36
 F src/hash.h ab34c5c54a9e9de2e790b24349ba5aab3dbb4fd4
 F src/hwtime.h 747c1bbe9df21a92e9c50f3bbec1de841dc5e5da
-F src/in-operator.md 973fe4522b871fb8cf683d8453760f4f19ac68c8
+F src/in-operator.md 9627b332c40228c0cb756eff1d84471b397539be
 F src/insert.c a255eb795cf475e7a0659297144fc80f70eb4e30
 F src/legacy.c 75d3023be8f0d2b99d60f905090341a03358c58e
 F src/loadext.c dd7a2b77902cc66c22555aef02e1a682554b7aec
@@ -1521,7 +1521,7 @@ F vsixtest/vsixtest.tcl 6a9a6ab600c25a91a7acc6293828957a386a8a93
 F vsixtest/vsixtest.vcxproj.data 2ed517e100c66dc455b492e1a33350c1b20fbcdc
 F vsixtest/vsixtest.vcxproj.filters 37e51ffedcdb064aad6ff33b6148725226cd608e
 F vsixtest/vsixtest_TemporaryKey.pfx e5b1b036facdb453873e7084e1cae9102ccc67a0
-P 25033ee94538289ba7e0147da30a18300047123f
-R e1cedb5c8edd4d27c5fcda8527491fbe
+P b6344298783a1207cba3f635939ddc9ba922ab67
+R 0bc7dc0041a27b5ec53385d0f7163e25
 U drh
-Z c3029179ef3a13ce81541f0730bc01a8
+Z 0df057355417cbdb73d372028cbbe733

manifest.uuid

@@ -1 +1 @@
-b6344298783a1207cba3f635939ddc9ba922ab67
+df0648373a50006ca18d692e12552d1d53d549e3

src/in-operator.md

@@ -61,9 +61,7 @@ algorithm is suboptimal, especially if there are many rows on the RHS.
 
 The following procedure computes the same answer as the simple full-scan
 algorithm, though it does so with less work in the common case.  This
-is the algorithm that is implemented in SQLite.  The steps must occur
-in the order specified.  Steps 1 and 3 are optional.  All other steps
-are required for correctness.
+is the algorithm that is implemented in SQLite.
 
   1.  If the RHS is a constant list of length 1 or 2, then rewrite the
       IN operator as a simple expression.  Implement
@@ -78,25 +76,21 @@ are required for correctness.
       IN operator is used for membership testing.  If the IN operator is
       driving a loop, then skip this step entirely.
 
-  2.  If the RHS is empty, return FALSE.
+  2.  Check the LHS to see if it is a partial-NULL and if it is, jump
+      ahead to step 4.
 
-  3.  If the LHS is a total-NULL, then return NULL.
+  3.  Do a binary search for the RHS using the LHS as a probe.  If
+      an exact match is found, return TRUE.
 
-  4.  If the LHS is non-NULL, then use the LHS as a probe in a binary
-      search of the RHS 
+  4.  If we do not need to distingish between FALSE and NULL,
+      then return FALSE.
 
-      4-A.  If the binary search finds an exact match, return TRUE
-
-      4-B.  If the RHS is known to be not-null, return FALSE
-
-  5.  At this point, it is known that the result cannot be TRUE.  All
-      that remains is to distinguish between NULL and FALSE.
-      If a NOT-TRUE result is acceptable, then return NOT-TRUE now.
+  5.  If the RHS is non-NULL then return FALSE.
 
   6.  For each row in the RHS, compare that row against the LHS and
-      if the result is NULL, immediately return NULL.  This step is
-      essentially the "Simple Full-scan Algorithm" above with the
-      tests for TRUE removed, since we know that the result cannot be
-      TRUE at this point.
+      if the result is NULL, immediately return NULL.  In the case
+      of a scalar IN operator, we only need to look at the very first
+      row the RHS because for a scalar RHS, all NULLs will always come 
+      first.  If the RHS is empty, this step is a no-op.
 
   7.  Return FALSE.