order of the columns in the row-value need to be rearranged in order to match
the index, be sure to make affinity conversions before the rearranging of
columns so that the correct affinity is applied. Fix for the bug
reported by [forum:/forumpost/eab63506cf|forum post eab63506cf]. This
problem goes back almost nine years to [ddb5f0558c445699].
FossilOrigin-Name: 8800c13deca3717c8a9bed42ef5f09752e4ca8a31adfb4ab0545e0e2b5684bd0
planner accept a WhereLoop for a row-value IN operator that uses the same
index column more than once.
FossilOrigin-Name: d2adf61f21a3ce901a2b08199ad0de191e88ef16e097c5f7a75c95ad958eff12
it causes a performance regression. Add new test cases for row-value lookups of
indexes that contain redundant columns, three of which are currently failing. This
branch is seeking an improved solution to the redundant index column problem for
row-value lookups.
FossilOrigin-Name: ad8ddcefab5cc526b1cd77731e00939c672e61ca83350d28961b67635d20da03
the ROWID as one of it columns, and then the columns of that UNIQUE are
used in a row-value IN operator as a WHERE clause constraint. Reported by
[forum:/forumpost/b9647a113b465950|forum post b9647a113b]. Problem
introduced by [723f1be3d4a905a6], part of ticket [da78413751863].
FossilOrigin-Name: d22475b81c4e26ccc50f3b5626d43b32f7a2de34e5a764539554665bdda735d5
is able to cope with row-value comparisons against the primary key index
of a WITHOUT ROWID table.
[forum:/forumpost/3607259d3c|Forum post 3607259d3c].
FossilOrigin-Name: 0620e419a927a3da6ebe921aaa3471686f0fdc2e485f4c2d5c88f32092228724
the main query into the various OR-term subqueries, do not push down slices
of a vector comparison, since the right-hand operand of the comparison might
have only been initialized in a different OR branch that was not taken.
dbsqlfuzz 80a9fade844b4fb43564efc972bcb2c68270f5d1.
FossilOrigin-Name: 9f67ad00cd38b7c5ec6d14b379e1a611777bbdf6901d843a80712ba7d94d6d33
check for NULL values and abort until after all key values have been
computed, in case one of the later key values involves some initialization
that is needed by a LEFT JOIN. Fix for the problem identified by
[forum:/forumpost/ab95010d410a0a55|Forum post ab95010d410a0a55].
FossilOrigin-Name: 4db5217a28ce767fa14ddfe51cf3ca25eceb72079d46a2fc00f7d6b8ae9abe0b
that resulted in an incorrect LEFT JOIN strength reduction when the
WHERE clause contained a row-value comparison.
Ticket [02aa2bd02f97d0f2]
FossilOrigin-Name: ea20068e6d97c9349ebcc7d0a01e99ebf08c6f44363f71a0218a1abea209adc5
has a COLLATE clause on the first term of the vector, be sure to honor that
COLLATE clause. Ticket [135c9da7513e5a97].
FossilOrigin-Name: 978b2d20cf95d0b7143e3104ce1e9d5c85002867b554dc6b21deb528b730bbc7
has an affinity that does not match the index.
Fix for ticket [6ef984af8972c2eb]
FossilOrigin-Name: 5c118617cf08e17a6edfdfba86e3fc49132a780990b68b52724c2aaeac85f506
operations on a PRIMARY KEY that contains duplicate columns.
Ticket [1a84668dcfdebaf12415d].
FossilOrigin-Name: dcb8c73594ea6b12bad98dc883a585d3e6b925c2ead267dc40332b3d266db5e8
format. Only some of the cases have been fixed. This is an incremental
check-in.
FossilOrigin-Name: 5f0e803e33aa557865d5fc830d9202d628de9a94c9757058ca48f1a560702cd3
existed every since row values support was added (version 3.15.0, 2016-10-14)
but was only just now detected by OSSFuzz.
FossilOrigin-Name: 2df6bbf1b8ca881c8a465d6624de66fde4c5975ccae6b2f2dda392b137f577de
for a WHERE clause on a row-value inequality. The incorrect table lookup
was causing an incorrect answer for the less-than operator.
Fix for ticket [f484b65f3d6230593c34f11]
FossilOrigin-Name: f3112e67cdb27c1aec8d2cee3cb91ade061d093e13505894698e26336898b336
in join queries with a term like "(a, b) IN (SELECT ...)" in the WHERE clause.
FossilOrigin-Name: 14dfd96f9bca2df5033b2d894bf63cc8bf450a45ca11df5e3bbb814fdf96b656
subexpressions when decomposing a vector comparison in the ON clause of
a LEFT JOIN.
Fix for ticket [fef4bb4bd9185ec8f].
FossilOrigin-Name: 619f5cc71774a37648e185c8502d7af14eb09b7f
