On Tue, May 5, 2009 at 2:17 PM, Josh Berkus wrote:
> Incompatible table changes would still require manual drop and recreation,
> of course. But most table changes to a production database are adding
> fields or changing constraints, which in most cases won't break dependant
> views or functions.
Josh Berkus writes:
> Incompatible table changes would still require manual drop and
> recreation, of course. But most table changes to a production database
> are adding fields or changing constraints, which in most cases won't
> break dependant views or functions.
... as indeed they don't.
All,
I was discussing this with a client who experiences this problem on a
weekly basis, and the issue is mainly one of change management.
That is, manually dropping all of the views & functions dependant on a
table, changing the table, and recreating the views and functions, is a
major PITA
Thanks a lot. I thought I would go with writing a function to Drop the views ,
ALTER table and the recreate the views so as to take care of the column type
changes in the table.
--- On Tue, 5/5/09, Tom Lane wrote:
From: Tom Lane
Subject: Re: [HACKERS] ALTER TABLE should change respective
Peter Eisentraut writes:
> And this could then also change the return type of foo(), thus changing the
> row type of the view and would thus propogate up to other views. And so if
> you have "many views", as you say, this could become a great mess. You could
> probably define and implement a s
On Monday 04 May 2009 23:11:22 Archana Sundararam wrote:
> I have many views dependent on a table. So whenever I do alter table and
> change the column type I have to drop and recreate all the views. Is there
> any other easy way to propagate the changes in the table to the views. Any
> suggestion
hi,
I have many views dependent on a table. So whenever I do alter table and change
the column type I have to drop and recreate all the views. Is there any other
easy way to propagate the changes in the table to the views.
Any suggestion is welcome.
Thanks,Archana
