Tom Lane <tgl@xxxxxxxxxxxxx> writes:
> In the cases I'm concerned about, DROP VIEW would fail unless you used
> CASCADE, and the subsequent CREATE VIEW would not magically bring back
> the dependent objects the CASCADE had killed. The entire *point* of
> REPLACE VIEW is that it does not have the side effect of destroying
> dependent objects; and therefore it has to act in a way that ensures
> the dependent objects still make sense. So, for the moment anyway,
> that means disallowing changes in the output column names and datatypes.
There have been a few times when people were confused by the way views adapted
to changes in their base tables. A typical example is when someone wants to
rename a column and then add a new column with the old name. They usually
expect the view to refer to the new column and not automagically change
definition to refer to the renamed column.
Based on the user reactions, it seems like the least-surprise behaviour would
actually be the naive implementation of keeping the raw text defining the view
and when anything changes in the base tables (or views) reinterpreting the
view based on the new context.
That would make both the ALTER TABLE and CREATE OR REPLACE VIEW behaviour
simple to implement. If you rename a column then any query using the view gets
an error until you put back a column with the name used.
It seems like this would be a huge behaviour change though. I don't suppose
the spec says anything about how views are supposed to respond to changes in
base context does it?
--
greg
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
