Thread: dependencies between objects

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?

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