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 …
[View More]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
[View Less]
