Greg Stark <gsstark@mit.edu> writes:
> 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?
SQL99 doesn't have RENAME COLUMN nor ALTER COLUMN TYPE, so the exact
cases don't arise, but I think this note under ALTER TABLE ADD COLUMN
is relevant:
NOTE 189 - The addition of a column to a table has no effect on
any existing <query expression> included in a view descriptor,
<triggered action> included in a trigger descriptor, or <search
condition> included in a constraint descriptor because any
implicit column references in these descriptor elements are
syntactically substituted by explicit column references under
the Syntax Rules of Subclause 7.11, "<query specification>".
Furthermore, by implication (from the lack of any General Rules
to the contrary), the meaning of a column reference is never
retroactively changed by the addition of a column subsequent
to the invocation of the <SQL schema statement> containing that
column reference.
The last sentence in particular seems to justify the way we do things
now.
The spec is also quite clear that DROP COLUMN (with CASCADE) destroys
any views that mention the column.
I see nothing at all in the spec that justifies the idea of "keep around
the source text and reinterpret it". They don't think that way; they
think in terms of thoroughly-processed "descriptors" stored in the
system catalogs.
regards, tom lane