Why would you need to store the historical versions of the stored procedures in a migrations folder? Wouldn't it be better to treat the stored procs like any other code, create a .sql file for each and keep them in version control? And then you can have a migration script that re-creates all the procs when you do an update.
Re:Total security in a PostgreSQL database
by yummyfajitas on Sunday February 09, 2014 @06:56AM
(#7205244)
Generally your migrations folder is supposed to store a complete history of your DB. Maybe doing it the way you suggest is a better way, it's just a bit outside the standard and to be honest I haven't thought carefully about the best way to structure code this way.
Re:Total security in a PostgreSQL database
by sonnym on Sunday February 09, 2014 @01:37PM
(#7206499)
Alex at The Daily WTF wrote a great article on this subject.
http://thedailywtf.com/Articles/Database-Changes-Done-Right....
Re:Total security in a PostgreSQL database
by penguindev on Sunday February 09, 2014 @10:45PM
(#7208981)
That's a decent read, but unfortunately even running the same precisely-versioned and ordered change scripts against dev, test, prod dbs can produce divergent results depending on the data in the db at the time. For example, prod could have a null somewhere, or data using a different url encoding flavor.... etc.
(Or if you're really lucky, even the current load on the database could make it fail... i.e. transaction serialization failure due to the random row order you attempted to lock)
So it should have ended with 'you're doomed'.
Nowadays I generally write raw SQL with the Tiramisu library (shameless plug: https://github.com/stucchio/Tiramisu ) I cooked up. It's basically writing straight SQL, but with the ability to safely do (almost) string concatenation to build queries.