seebs b35c240da7 handle count(*) in having correctly (#2274) ... * correct reference for `having count(*)` It turns out that `having count(*) ...` was always treating the count(*) as exactly 1. After studying this a lot, I noticed that in fact, we correctly handle other counts. The reason is that there's already code to recognize aggregates in `having` clauses as matching aggregates that are being computed -- but it only covers the other aggregate clause types, not the newly added `countStarPlanExpression` from making `count(*)` work even if there's no `_id` field. We add several corresponding test cases. * fix sum(a_decimal) type conversion Added a test case for this, and also added a fix for it. Underlying issue: qualifiedRefPlanExpression could end up producing an int64 instead of a pql.Decimal, even though it had expected type Decimal. Originally this worked by politely converting an int64 to a pql.Decimal in the Evaluate phase, but this was not ideal; the real question is why it was coming out as an int64 at that step. Showed this to Pat, who spent a while studying it and produced a better fix. * temporarily comment out test which fails in DAX		2023-03-01 23:49:45 -06:00
..
defs	handle count(*) in having correctly (#2274)	2023-03-01 23:49:45 -06:00
helpers.go	Aggregation Nation (fb-1955, fb-1887) (#2252)	2023-02-16 10:56:27 -06:00