Hi, I'm the author of that article. Yes, that was the first thing that came to my mind when I noticed the error messages but it wasn't really an option by that

Hi, I'm the author of that article. Yes, that was the first thing that came to my mind when I noticed the error messages but it wasn't really an option by that point because I could no longer add new columns to that table. I wanted to enable the deals porting as soon as possible and I didn't know yet by that time how to rewrite the table without asking for some maintenance window, so I decided to go with another solution. If you're curious why I didn't simply create that column permanently in the first place, the reason is that this was supposed to be a one-off script (it would run multiple times but just during the transition to the new template until all deals would have been ported) and I didn't want to pollute the table or have to remember to drop that column in a future time. There are also other reasons why I don't think it would be a good idea. The script was greatly simplified with the assumption that all rows having a value in the previous_id column would be related to that deal being ported. If I want to keep the same simple logic I'd have to make sure the script would delete any values from that column in the beginning of the transaction and I figured that could increase the chance of conflicts in case of concurrent attempts of porting deals and I didn't want to have to bother about concurrency issues so I didn't want to even think about that. With a temporary column I knew I wouldn't have to worry about that.