Hi team,
I like the Oct2020 release very much.
It has some discontinuities with past releases, and that's ok.
One that I find a bit too painful though is the stricter time and interval typing. Not that I am against it, it is now more SQL compliant. But perhaps the transition could have been a bit softer.
It boils down to date arithmetics between temporal and numeric types.
Something like this was allowed before:
1 + (date1 - date2) (integer + interval)
As the release notes say, a new function epoch_ms() has been added to help the transition. This function can turn dates and intervals into the number (int) of milliseconds since 1970-01-01 00:00:00 UTC.
So if one really needs such arithmetics, could do something like
1 + epoch_ms(date1 - date2)
The problem with this is that this function was not available in earlier releases. This makes the migration of existing applications very hard, because there is no combination that works in all cases:
Deployed application Old MonetDB New MonetDB int + interval works fails int + cast(interval as int) works fails int + epoch_ms(interval) fails works
As you see, there is no overlap between the solutions that worked with MonetDB < Oct2020 and those that work with MonetDB Oct2020.
I wonder, would it have been such a bad idea to make the transition as it was done, but leave the ability to cast an interval to a number? At least for a couple of releases?
We are now facing the issue that if we want to roll forward to MonetDB Oct2020, at the same time we need to make sure to redeploy our code to be compatible with it. There is so much that could go wrong with this! It's scary. I've nothing against breaking backward compatibility, but honestly I don't see the urgency in removing that cast, it would have helped a lot.
Roberto Cornacchia +31 (0) 6 27 232 270 www.spinque.com