Conversation
Changing only a column comment did not require altering the column type or collation on backends that support standalone COMMENT ON COLUMN statements. Using the standalone comment statement avoided unnecessary ALTER COLUMN SQL on PostgreSQL and Oracle while preserving the existing fallback for other backends.
There was a problem hiding this comment.
Hello! Thank you for your contribution 💪
As it's your first contribution be sure to check out the patch review checklist.
If you're fixing a ticket from Trac make sure to set the "Has patch" flag and include a link to this PR in the ticket!
If you have any design or process questions then you can ask in the Django forum.
Welcome aboard ⛵️!
tim-mccurrach
left a comment
There was a problem hiding this comment.
@imcatta Thanks for the contribution :)
From a cursory read, this looks like it is logically very similar to the change made by this existing PR. Is there a reason we need a new PR to replace it? The other one just needs a review, so it'd be better to review that one rather than open a brand new PR.
|
@tim-mccurrach I completely missed the other PR, thanks for pointing it out 🙏 |
Trac ticket number
ticket-36947
Branch description
This branch introduces support for standalone
COMMENT ON COLUMNstatements on PostgreSQL and Oracle when only a column comment changes. This avoids unnecessaryALTER COLUMNoperations, reducing lock severity (SHARE UPDATE EXCLUSIVEinstead ofACCESS EXCLUSIVE) and preventing migration failures involvingGeneratedFields or columns backed by database views, while preserving the existing fallback behavior for other backends.AI Assistance Disclosure (REQUIRED)
Checklist
mainbranch.