When determining whether an == or IS constraint in a WHERE clause makes an ORDER BY term redundant, consider the collation sequence used by the == or IS comparison, not the collation sequence of the comparison expression itself. Possible fix for [fb8c538a8f].

FossilOrigin-Name: 16aed5d0c63dcdc2054dbb8a4b6b992476640433bf81e19301e6db5a3fc82633

1 files changed, 5 insertions, 2 deletions

diff --git a/src/where.c b/src/where.c
index e7447deec..de384dd95 100644
--- a/src/where.c
+++ b/src/where.c
@@ -3752,8 +3752,11 @@ static i8 wherePathSatisfiesOrderBy(
         if( j>=pLoop->nLTerm ) continue;
       }
       if( (pTerm->eOperator&(WO_EQ|WO_IS))!=0 && pOBExpr->iColumn>=0 ){
-        if( sqlite3ExprCollSeqMatch(pWInfo->pParse, 
-                  pOrderBy->a[i].pExpr, pTerm->pExpr)==0 ){
+        Parse *pParse = pWInfo->pParse;
+        CollSeq *pColl1 = sqlite3ExprNNCollSeq(pParse, pOrderBy->a[i].pExpr);
+        CollSeq *pColl2 = sqlite3ExprCompareCollSeq(pParse, pTerm->pExpr);
+        assert( pColl1 && (pParse->nErr || pColl2) );
+        if( pColl2==0 || sqlite3StrICmp(pColl1->zName, pColl2->zName) ){
           continue;
         }
         testcase( pTerm->pExpr->op==TK_IS );