Avoid a malfunction that could occur if the same correlated column reference appears in both the GROUP BY and the HAVING clause of a sub-select. dbsqlfuzz a779227f721a834df95f4f42d0c31550a1f8b8a2.

FossilOrigin-Name: 1e35cc6d5c2f563c6bb163bb150d7bc6ede4c993efa828af1face3261bf65a2c

1 files changed, 8 insertions, 0 deletions

diff --git a/src/select.c b/src/select.c
index e0ac9db97..b74999a8f 100644
--- a/src/select.c
+++ b/src/select.c
@@ -6019,8 +6019,16 @@ static void explainSimpleCount(
 static int havingToWhereExprCb(Walker *pWalker, Expr *pExpr){
   if( pExpr->op!=TK_AND ){
     Select *pS = pWalker->u.pSelect;
+    /* This routine is called before the HAVING clause of the current
+    ** SELECT is analyzed for aggregates. So if pExpr->pAggInfo is set
+    ** here, it indicates that the expression is a correlated reference to a
+    ** column from an outer aggregate query, or an aggregate function that
+    ** belongs to an outer query. Do not move the expression to the WHERE
+    ** clause in this obscure case, as doing so may corrupt the outer Select
+    ** statements AggInfo structure.  */
     if( sqlite3ExprIsConstantOrGroupBy(pWalker->pParse, pExpr, pS->pGroupBy) 
      && ExprAlwaysFalse(pExpr)==0
+     && pExpr->pAggInfo==0
     ){
       sqlite3 *db = pWalker->pParse->db;
       Expr *pNew = sqlite3Expr(db, TK_INTEGER, "1");