I think the approach is problematic in many ways and strongly suggest to reconsider before it has been released.
According to JIRA and the commit comment, what it was trying to solve sounds like relatively minor inconsistencies. It does solve them, but at the cost of introducing bigger ones, adding unnecessary limitations, and hurting usability.
Let's take the test case from
MDEV-28918 description as a basis.
The complaint there was that under the same circumstances, UPDATE and ALTER produced identical warnings but the automatic cast ended up with different inet6 values, :: vs NULL.
The achievement is that now they behave identically.
Now both UPDATE and ALTER ignore non-strict SQL_MODE and IGNORE modifier in ALTER and UPDATE completely, they don't change the behavior anymore, even though they should and still do for most data types.
The error/warning message has changed from a quite useful, containing the problematic value, table name, column name, (and row number, which may be not always correct, but it was at least trying) to an incomprehensible and useless generic complaint:
I personally couldn't understand what it meant until I removed all irrelevant values and columns, got to inserting only one wrong row in one column, and only then, judging by what I was doing, I could guess what the message was trying to say. I cannot imagine how users can understand the problem in a real setup with many rows and many columns.
Now conversion into INET6 and alike from INT and some other types behaves differently comparing to string types/literals, which is a much more visible inconsistency than the one that was being solved:
That is, it has no problem converting an integer passed as a string (or any string, for that matter), but has a problem converting the integer itself. Same with other types, e.g. temporal.
So far, two arguments were briefly discussed on Slack:
this isn't completely unheard of. GEOMETRY does the same.
This is true; however, geometry types have always been somewhat special and notoriously weird, their behavior in this sense appears to be a limitation, more or less adequately explained by the error message itself (which btw has also been damaged by
Well, if it really cannot, then it cannot. There is no reason to extend the legacy deviations onto new data types unless absolutely necessary. We know that INET6 or UUID have no problem casting to a valid value, they did before. Which leads to the 2nd mentioned point:
It's what you can expect from a data type that doesn't have a natural "default" value. Although, one can use all-zeros as a natural ipv6 value, so may be it shouldn't have GEOMETRY behavior. uuid doesn't have a natural default though
"Natural" is a subjective term. We use 0000-00-00 as a default value for dates, which is anything but natural. In any case, both INET6 and UUID have a "hard default" value, and still do even after the change, so it's not really an excuse:
And with INET6 it is even more naturally ::.
Btw, it is a weak excuse even for geometry, as it's capable of inserting an empty string when it wants to, but it wants to so inconsistently that it would not be helping my case.