-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dont duplicate CHECK
constraints and DEFAULT
s when altering column type
#349
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I understand this doesn't affect other constraints, like UNIQUE or NOT NULL right?
I'm wondering if this will be unexpected for compatible types, ie when I cast from integer to int8 or float 🤔 |
That's right, only defaults and check constraints are affected |
That was my concern too. If we had done this before supporting multiple sub-operations in one alter column statement it would probably not have been the right decision. Now however if you change type to a compatible type you can recreate the {
"name": "35_alter_column_multiple",
"operations": [
{
"alter_column": {
"table": "users",
"column": "age",
"type": "bigint",
"default": "0",
"check": {
"name": "age_check",
"constraint": "age > 21"
},
"up": "...",
"down": "..."
}
}
]
} which mitigates the problem, although it might still be unexpected that you have to do this. Ideally we would try to preserve checks and defaults iff they are compatible with the new type. |
We should preserve defaults and check constraints when they are compatible. Putting this back into draft in order to do that. |
c7b765d
to
549d0cf
Compare
Updated this to preserve |
When a column is duplicated with a new type, check constraints and defaults defined on the column *may* be incompatible with the new type. In this case column duplication should not fail, but rather the incompatible constraints and defaults should be ignored and not be duplicated to the new column.
When changing a column type, incompatible defaults should be removed from the column.
When changing a column type, incompatible checks should be removed from the column.
549d0cf
to
54e2763
Compare
When a column is duplicated with a new type, check constraints and defaults defined on the column may be incompatible with the new type.
In this case column duplication should not fail, but rather the incompatible constraints and defaults should be ignored and not be duplicated to the new column.
This PR changes column duplication to ignore errors on
DEFAULT
andCHECK
constraint duplication that look as though they are caused by a change of column type.Fixes #348