Thanks for reply Christian..
On Wed, May 31, 2017 at 7:18 AM Christian Beikov <christian.beikov(a)gmail.com
wrote:
Looks good. OTOH I'd also like to see the following functions
* millisecond_diff
* second_diff
* minute_diff
* hour_diff
* day_diff
* week_diff
* month_diff
* quater_diff
* year_diff
Why not basic temporal arithmetic? E.g. `second(x) - second(y)` (which
isgenerally resolved to `extract(second from x) - extract(second from y)`...
* epoch - generally defined as `extract(epoch from ?1)`
Because ANSI SQL does not define epoch as an extractable part of a
temporal. TBH I do not think it defines milliseconds as extractable either
but would have to check. Also, I am not sure of databases that support
that, nor any alternate (which we'd *need* to support this as a standard
func) for databases which do not.
* group_concat - string aggregation function
How is this different from concat()?
> The group_concat function would probably be not be possible to implement
> for all DBMS, but at least the bigger ones have one or the other
> function that could be used to implement this.
Unless I am missing something in your idea here (which is why I asked
above) we can absolutely implement this on all databases - everyone has a
concat operator as well. And a SQM/SQL-AST function need not evaluate to a
db function - it just needs to be an expression.
Don't know what is best regarding the "str" function.
`str()` is defined as `cast`; that's not the issue. The issue is merely
the type - I am simply arguing that VARCHAR is more correct