| Bug #86098 | change on Foreign Key Modify behaviour (ER_FK_COLUMN_CANNOT_CHANGE) | ||
|---|---|---|---|
| Submitted: | 26 Apr 2017 21:18 | Modified: | 26 May 2017 23:18 |
| Reporter: | Matthieu Larcher | Email Updates: | |
| Status: | No Feedback | Impact on me: | |
| Category: | MySQL Server: Parser | Severity: | S3 (Non-critical) |
| Version: | 5.6.36 | OS: | Linux |
| Assigned to: | CPU Architecture: | Any | |
[26 Apr 2017 23:18]
MySQL Verification Team
Thank you for the bug report. Please provide the repeatable complete test case script not a partial comment of it. Thanks.
[27 May 2017 1:00]
Bugs System
No feedback was provided for this bug for over a month, so it is being suspended automatically. If you are able to provide the information that was originally requested, please do so and change the status of the bug back to "Open".
Description: Version tagged 5.6.36 introduced a breaking change in the way MODIFY instruction on columns with a foreign key are handled: 5.6.35 accepts the change, while 5.3.36 fails with a ER_FK_COLUMN_CANNOT_CHANGE error. Can we assume that the image versioning respects semver and that this is just a mishap that should be fixed rapidly, or should we consider semver not to be of concern in the actual versioning scheme ? And is this a case of "it's not a bug it's a feature", or will that be fixed soon ? How to repeat: try to use `ALTER TABLE sometable MODIFY COLUMN somecolumn bigint(20) DEFAULT NULL;` when somecolumn is a foreign key Suggested fix: either allow as it was the case before, or bump to a major version if semver is to be respected