Fix to check-in [b9190d3da70c4171] - the agg-with-indexed-expr optimization

requested by ticket [99378177930f87bd] - that can cause an incorrect answer
if an aggregate subquery has a GROUP BY clause, and that GROUP BY contains a
term that is not in the result set, and the outer query makes use of expression
indexes.  Problem reported by
[forum:/forumpost/a68313d054|forum post a68313d054].

FossilOrigin-Name: e06973876993926fd56181281d04b8dd504c689abf883fa21a5721cc1d478ea8

1 files changed, 3 insertions, 1 deletions

diff --git a/src/select.c b/src/select.c
index 359dc8cf3..2906a4895 100644
--- a/src/select.c
+++ b/src/select.c
@@ -6439,10 +6439,12 @@ static void optimizeAggregateUseOfIndexedExpr(
   NameContext *pNC        /* Name context used to resolve agg-func args */
 ){
   assert( pAggInfo->iFirstReg==0 );
+  assert( pSelect!=0 );
+  assert( pSelect->pGroupBy!=0 );
   pAggInfo->nColumn = pAggInfo->nAccumulator;
   if( ALWAYS(pAggInfo->nSortingColumn>0) ){
     if( pAggInfo->nColumn==0 ){
-      pAggInfo->nSortingColumn = 0;
+      pAggInfo->nSortingColumn = pSelect->pGroupBy->nExpr;
     }else{
       pAggInfo->nSortingColumn =
         pAggInfo->aCol[pAggInfo->nColumn-1].iSorterColumn+1;