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 t...@sss.pgh.pa.us wrote:
From: Tom Lane t...@sss.pgh.pa.us
Subject: Re: [HACKERS] 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 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 solution, but it would be very confusing and
risky to use.
The SQL committee has also historically chosen to punt on such things.
Note the long-established rule that * is expanded at view definition
time (so adding columns doesn't change views). I also see a flat
prohibition on *any* view reference in the newly added SET DATA TYPE
command (SQL:2008 11.17 alter column data type clause):
7) C shall not be referenced in the query expression of any view descriptor.
regards, tom lane
