featurebase/sql3
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
..
parser forward-port tests from SQL1 tree (#2261) 2023-03-01 13:40:50 -06:00
planner handle count(*) in having correctly (#2274) 2023-03-01 23:49:45 -06:00
test handle count(*) in having correctly (#2274) 2023-03-01 23:49:45 -06:00
errors.go add support for time quantum inserts with explicit timestamps (fb-1558) (#2262) 2023-02-17 12:06:46 -06:00
interfaces.go introduce performance counters and system table fanout, plus refactor metrics (#2363) 2023-01-19 21:35:02 +00:00
main_test.go added testify dependency 2022-09-30 11:31:37 -07:00
sql_complex_test.go FB-1968 timestamp data type related fixes and enhancements (#2256) 2023-02-24 14:57:17 -05:00
sql_test.go forward-port tests from SQL1 tree (#2261) 2023-03-01 13:40:50 -06:00