[MDEV-26075] alter column drop default syntax creates inconsistent table behavior Created: 2021-07-01 Updated: 2021-07-17 |
|
| Status: | Open |
| Project: | MariaDB Server |
| Component/s: | None |
| Affects Version/s: | 10.5.5 |
| Fix Version/s: | 10.5, 10.6 |
| Type: | Bug | Priority: | Major |
| Reporter: | Allison Hume | Assignee: | Oleksandr Byelkin |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | None | ||
| Environment: |
CentOS 7.8 |
||
| Description |
|
Running the command "alter column drop default" creates an inconsistent table behavior where the column appears to not have a default but insertion without a value specified for this column succeeds. How to reproduce: Use the following table. For this example I'm using schema 'test':
The default allows insertion without specifying a value for 'at', as expected:
Now run an alter table statement as follows:
Using the default() statement makes it appear that this removed the specified default:
However, the create table statement still shows the default, and it's still possible to insert into example_table without providing a value for the 'at' column:
From the documentation it's not clear to me if perhaps the 'drop default' is expected to revert to the 'initial default' for the column data type, which would still be current_timestamp(), instead of removing the default and putting the column definition to "`at` datetime NOT NULL". The current behavior, however, seems to be a combination of the two where the default() command behaves as if the column definition is "`at` datetime NOT NULL", but otherwise the table behaves as if it still has the default as current_timestamp(). |