RENAME TO immediately makes the table available under its new name of sprocket. Here’s some copy/pastable migration code for renaming a table (in this example, chainwheel -> sprocket): BEGIN Īnd with a post-deploy (after all clients are rotated) follow up of: DROP VIEW chainwheel Luckily, Postgres makes this possible relatively easily. We’d like to rename things, but to also do so with zero downtime and zero user impact. Copy this codeīut to schema hygiene fanatics out there (like myself), that’s not a satisfactory answer. I’d hazard to guess that this is how most shops run – people would generally prefer to rename as appropriate, but in practice it’s more time, risk, and effort than it’s worth. Practically speaking, the easiest way to administer a production database is to never rename anything, and live with the fact that some names are less-than-optimal. It’s annoying for users, and painful if a service is doing some business critical. Anything that was still running against the old name when a rename takes place will immediately break, causing downtime and major user impact.Īn alternative would be to disable all clients temporarily and then do the rename, and indeed a “we’re down for maintenance” screen was a pretty common sight in the 2000s, but serious services in the 2020s aim to never have downtime at all. The problem isn’t in the database itself, but in database clients. Anyone who’s run a production database before will recognize that outside of an academic context, it’s actually kind of hard. The SQL is a dead simple one-liner of ALTER. At first glance, renaming entities in a database seems like it should be easy.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |