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 is
Peter Eisentraut pete...@gmx.net 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
] ALTER TABLE should change respective views
To: Peter Eisentraut pete...@gmx.net
Cc: pgsql-hackers@postgresql.org, Archana Sundararam archn...@yahoo.com
Date: Tuesday, May 5, 2009, 8:10 AM
Peter Eisentraut pete...@gmx.net writes:
And this could then also change the return type of foo(), thus changing
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
Josh Berkus j...@agliodbs.com 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
On Tue, May 5, 2009 at 2:17 PM, Josh Berkus j...@agliodbs.com 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
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
