Em Friday 16 November 2007 18:57:24 Ed L. escreveu: > > I often have need for views that reference views that reference > views, and so on. When I need to make a small update to one of > the views, I am faced with having to drop and recreate all > dependent views even if the driving change just adds another > column to the view, for example. I might have to drop and > recreate many tens of views just to make a change to a single > view. What a PITA. How do others manage this? I have the same problem. DB2 does have some kind of path invalidation where you have to recreate the path to make your views usable again. So, it is possible to work with views like "SELECT * FROM table" to leverage table changes and things like that. If PostgreSQL had similar resources to "block" the usage of a (some) view(s) until another command was issued to prevent that need of dropping and recreating all dependent objects it would be great. A suboptimal alternative would be allowing the number of columns be greater than it was before -- i.e., add new columns to the view --, but block name changes for those columns and removing columns. -- Jorge Godoy <jgodoy@xxxxxxxxx> ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
