Name collisions for op min and max functions. about arquero HOT 4 CLOSED

Thanks! I will fix this as part of the upcoming v4.0.0 release. We just need to determine what the naming scheme will be. I'm tempted to leave op.min and op.max as aggregate functions. Though this is non-obvious syntactically, it matches the prior releases and will not break existing code. I also think the aggregate functions are the more common use case. (The fact that this issue hasn't been raised until now attests to that, I think.)

If so, that leaves the question of what to name the "standard" min and max functions. One "trick" we can add is to update the parser so that if Math.min and Math.max appear in a table expression we use the standard versions (we already auto-magically map Math. constant lookups). As for the op namespace itself, maybe op.max_value and op.min_value?

from arquero.

I've used op.max for aggregations and it works fine. I think it's better reserved as current scenario.

I wonder is there any easy way of function overloading? Since the parameters are not the same in these scenarios, for aggregation it needs to be one, but for math scenario it needs to be two and more.

Another idea is to breakdown 'op' with categorical namespacing, like op.max === op.aggregationFunctions.max, op.Math.max, op.String.indexof etc, in case of other collisions. But it is not a very elegant solution.

from arquero.

I’m not sure if it’s part of the ISO standard, but I believe that a lot of SQL dialects use “greatest” and “least” for this. https://docs.aws.amazon.com/redshift/latest/dg/r_GREATEST_LEAST.html

from arquero.

Thanks @jcmkk3! I was thinking along those lines after realizing max_value, etc. is too similar to existing window functions. Good to see some precedent for this in existing DB systems.

from arquero.