Toni Casueps wrote:
I have got some views (for example view B) that use another views (for
example view A) in the FROM clause.
If I want to change view A, and it doesn't allow me to (for example
adding a new column), another way would be dropping A and recreating it
with the new column, but it doesn't allow me to drop view A because B
depends on it, nor overwriting A with the new one because it already
exists. One thing I can do is rename A to A_ , create the new A and drop
A_ but it automatically reassociates B to depend on A_ , not in the new
A I just created.
Is there a way to disable any of these restrictions?
No. If you did PG couldn't guarantee that B would carry on working.
What you want to do is put your view definitions into a file with
BEGIN...ROLLBACK at the start and end which drops everything necessary.
Once your SQL doesn't produce any errors switch the ROLLBACK for COMMIT.
--
Richard Huxton
Archonet Ltd
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
