Scott, I implemented a system exactly like this for the app in my signature below. Basically the system stores metadata containing each view definition and the joins between them. When someone needs to alter a view, say to remove a column, a DROP CASCADE is performed then each view is recreated in turn *in the correct order*. Everything's in a transaction, so a failure of recreation will roll back to the original state. This can of course happen if for example a column is deleted which other views use. This method is only used if the original attempt fails due to dependency errors - some view updates can work just fine anyway. I can point you to the relevant code in GitHub if you're interested (it's Java). Regards Oliver Kohll oliver@xxxxxxxxxxxxxxx / +44(0)7814 828608 / skype:okohll www.agilebase.co.uk - software www.gtwm.co.uk - company On 24 Apr 2010, at 13:01, Scott Bailey <artacus@xxxxxxxxxxx> wrote: Using views in Postgres can be a painful process. Changing a column in a base table will require you to drop all views that depend on it, and all views that depend on those views and so on. |