"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> "Robert Haas" <robertmhaas@gmail.com> writes:
>> I think the real problem here is that PostgreSQL is very finicky about
>> what operations you can perform on a view. If I have a table foo and
>> I define a view bar that uses foo and a view baz that uses bar, I can
>> add a column to foo without a problem, and, similarly, I can also drop
>> or alter a column in foo that is not used by bar. But the same is not
>> true of bar.
>
> Yeah. The current restrictions were set when CREATE OR REPLACE VIEW
> was first implemented, and at that time we didn't have very much
> ALTER TABLE capability at all; the view restrictions mirror what we
> could do with a table at the time. It would be worth revisiting
> that to make it square up with what you can now do to a table.
I thought the problem had more to do with the former lack of query
invalidation. If someone altered the view we had no way to replan any plans
from a former definition of the view.
Now that we have the query cache would we know that the view had changed and
therefore the whole query needs to be replanned from source?
-- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's On-Demand Production
Tuning