Ricardo Sanchez

Sometimes, doing things faster causes you to spend more time on them in the end. As much as I pray about taking things slow and avoiding multitasking, today I fell victim to my own desire to speed things up. While at work, I made some changes to a database migration script to rename a couple of properties. I ran them locally, one at a time, and assumed they were okay. The updated script was supposed to fix an issue discovered in a test environment, and I was eager to deploy it as soon as possible.

After merging my changes, I waited for the deployment to start and, to my surprise, it failed. After some research, I found out that the reason it failed wasn’t my change, but an issue with one of the virtual computers running the deployment. I retried the deployment and, a few minutes later, it failed again. This time, it was due to my change.

The error was due to how PostgreSQL handles column name updates for views. If you use the command create or replace view, PostgreSQL will fail when renaming a column. I would have learned about this if I had paid attention to the documentation:

CREATE OR REPLACE VIEW is similar, but if a view of the same name already exists, it is replaced. The new query must generate the same columns that were generated by the existing view query (that is, the same column names in the same order and with the same data types), but it may add additional columns to the end of the list. The calculations giving rise to the output columns may be completely different.

https://www.postgresql.org/docs/current/sql-createview.html

One solution is to drop the view first and then recreate it with the new column name(s) or use the alter view command. I hadn’t done this, so the deployment failed because the script lacked an explicit command to drop the view first. 🤷🏽‍♂️

It was a simple fix, but not paying enough attention to the change I was committing resulted in over an hour of waiting to see the changes in the testing environment. This was due to creating not one, but two pull requests (PRs), and waiting for two instead of one deployment.

All of this could have been easily avoided if I had gone slowly, paid attention to the script I was writing, tested the script itself and not just the rename locally, and then created a single PR with my changes to have them deployed once to the test environment. Instead of waiting for more than an hour, it could have taken just minutes.

That’s my lesson and an important reminder today: focus and spend the necessary time on the task at hand. Doing so will save you time, frustration, and possibly embarrassment in the end—a not bad trade for spending a little more time upfront.

To all my readers and fellow tech enthusiasts, I’m thrilled to introduce Diary of a Developer. In this series, you’ll get an inside look at my adventures in technology—everything from code snippets to crisis management, personal anecdotes and insights from my everyday professional experiences. It’s a look at the real ups and downs that come with being a developer, and I hope it helps others learn from my experiences.

Cheers.