Having clause does not work on complex aggregators

[himanshug]

I tested it for groupBy and found following behavior.

Having clause eval function receives row with unfinalized values. So, if you had a hyperUnique or thetaSketch aggregator and applied having on same then that doesn't work. A workaround is to have a post aggregator in the query that finalizes the aggregator value(and creates a number or a type that Having impls understand) and then ask for having on this post aggregator.

One of my users got bitten by it and generally user expectation would be that it should just work. Not sure if above workaround should be the official answer or we should consider it a bug.

[gianm]

IMO the best behavior is for the HavingSpec interface in general to get unfinalized values (what if you wanted to filter on a property of the unfinalized object?), but for most of the built-in HavingSpec implementations to finalize their inputs, since they cannot do anything useful with unfinalized values.

[himanshug]

I see that HavingSpec already got a setRowSignature(..) . we can probably add void setAggregators(Map<String, AggregatorFactory>) to HavingSpec class. Update greater-than/less-than/equal-to implementations to do AggregatorFactory.finalize(value = row.get(xx)) on eval(row)

[himanshug]

or maybe generic void setFinalizers(Map<String, Function>) method on HavingSpec . Caller would put aggregatorFactory::finalize in that map.

[himanshug]

@gianm does #4859 (comment) sound ok ?