vitessio/vitess · error

unsupported aggregation function: %v

Error message

unsupported aggregation function: %v

What it means

Aggregate functions found in unexpected positions (outside the handled count/sum analysis paths) are rejected by the sqlparser.Walk in the non-aggregate expression branch. Only top-level count(*) and single-column sum are supported; e.g. an aggregate nested inside a scalar expression like ABS(sum(x)) triggers this.

Source

Thrown at go/vt/vttablet/tabletmanager/vreplication/table_plan_builder.go:530

			cexpr.operation = opSum
			cexpr.expr = innerCol
			tpb.addCol(innerCol.Name)
			cexpr.references[innerCol.Name.String()] = true
			return cexpr, nil
		}
	}
	err := sqlparser.Walk(func(node sqlparser.SQLNode) (kontinue bool, err error) {
		switch node := node.(type) {
		case *sqlparser.ColName:
			if !node.Qualifier.IsEmpty() {
				return false, fmt.Errorf("unsupported qualifier for column: %v", sqlparser.String(node))
			}
			tpb.addCol(node.Name)
			cexpr.references[node.Name.String()] = true
		case *sqlparser.Subquery:
			return false, fmt.Errorf("unsupported subquery: %v", sqlparser.String(node))
		case sqlparser.AggrFunc:
			return false, fmt.Errorf("unsupported aggregation function: %v", sqlparser.String(node))
		}
		return true, nil
	}, aliased.Expr)
	if err != nil {
		return nil, err
	}
	cexpr.expr = aliased.Expr
	return cexpr, nil
}

// addCol adds the specified column to the send query
// if it's not already present.
func (tpb *tablePlanBuilder) addCol(ident sqlparser.IdentifierCI) {
	tpb.sendSelect.AddSelectExpr(&sqlparser.AliasedExpr{
		Expr: &sqlparser.ColName{Name: ident},
	})
}

View on GitHub (pinned to 01a25a7d17)

Solutions

  1. Use the aggregate bare at the top level of a select-list item: SELECT sum(x) AS sum_x FROM t.
  2. Apply post-processing (abs, +1, etc.) after materialization, in the consumer query.
  3. Stick to the supported set: count(*) and sum(single unqualified column).

Example fix

// before
select abs(sum(x)) as a from t
// after
select sum(x) as sum_x from t
Defensive patterns

Strategy: validation

Validate before calling

// Ensure each select item is either a plain column or a bare top-level count(*)/sum(col)
func supportedSelectItem(e sqlparser.Expr) bool {
    ag, ok := e.(*sqlparser.AliasedExpr)
    if !ok { return false }
    switch x := ag.Expr.(type) {
    case *sqlparser.ColName, *sqlparser.CountStar:
        return true
    case *sqlparser.Sum:
        col, ok := x.Args[0].(*sqlparser.ColName)
        return ok && col.Qualifier.IsEmpty()
    }
    return false
}

Type guard

func isBareAggr(n sqlparser.SQLNode) bool { switch n.(type) { case *sqlparser.CountStar, *sqlparser.Sum: return true }; return false }

Prevention

When it happens

Trigger: Materialize/vreplication SELECT where an aggregate appears inside a larger expression, e.g. SELECT abs(sum(x)) AS a FROM t; the walk visits the sqlparser.AggrFunc node and errors.

Common situations: Users wrapping aggregates in functions or arithmetic (sum(x)+1) assuming expression support; porting general SQL into a materialize workflow.

Related errors


AI-assisted analysis of vitessio/vitess@01a25a7d17 (2026-09-01). Data as JSON: /api/errors/ae97e32f61ac7259. Report an issue: GitHub.