Dear all, The current implementation of views uses OIDs, not table/view names. As a consequence, when you happen to replace (drop then create) an underlying table or view, you also have to drop and recreate all views using this table|view (and this recursively, of course ...).
I stumbled on this while doing repeat analyses (involving repeated uses of aggregation) of the same dataset using slight variations of the subset of interest. When my dataset was small, I used to do that in (yuck !) MS-Access by creating a view defining the subset of interest, then creating views based on this view, and so on... Now that my dataset is too large to be Access-manageable, I migrated it to PostgreSQL (which, BTW, gave me nice performance enhancements), but I had to change my working habits. I have now to create a script defining my views, then to run it at each and every variation of the subset of interest ... To be able to conserve existing views would definitely be a bonus. Of course, the overhead is necessary to handle the general case. However, there is a special case where this is unnecessary : when the new table or view "class" definition is a (possibly improper) subclass of the original one, or, if you prefer, when the column set of the new definition is a (possibly improper) superset of the old one. For tables, this case is already handled by a judicious use of alter table, at least in its present form (adding DROP COLUMN, which might be an interesting feature for other reasons, entails the risk of invalidating existing views ...). However, there is currently no easily reachable way to do that for a view (I suppose that the special case of modifying the definition of a view creating the same columns in the old and new definitions might be possible with a "clever" (ab)use of system catalogs, but I tend to be *very* wary of such hacks ...). Of course, I am aware that view definitions aren't just stored, but that a lot of rewriting is involved before storing the actual execution plan. Modifying a view definition would entail re-processing of other view definitions. But so is the case with the modification of a table ... What do you think ? -- Emmanuel Charpentier ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
