Re: About "Allow VIEW/RULE recompilation when the underlying tables change"

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Dec 18, 2009 at 9:58 PM, suzhiyang <suzhiyang(at)gmail(dot)com> wrote:
>> I'm doing the Todo List's "Allow VIEW/RULE recompilation when the underlying
>> tables change ".

> I am not sure what this TODO item is supposed to refer to, but saving
> the query string and re-executing it is clearly not acceptable. What
> if a column or table or function referenced in the query has been
> renamed since the view/rule was created?

The TODO item is terribly underdocumented, but I think what it's on
about is that right now we refuse commands like ALTER COLUMN TYPE if
the column is referenced in a view. It would be nice to propagate
such a change into views if possible. The hard part is that the view
might contain operations on the column --- such as "func(x)" or "x+1"
or "ORDER BY x" --- so you'd have to determine new semantics for those,
which is why the term "recompilation" seems appropriate.

The other point that is alluded to in the TODO item is that if the view
was originally specified as "SELECT * FROM foo" then one might wonder
whether ALTER TABLE foo ADD COLUMN bar adds the new column to the view
too. Now the SQL standard is perfectly clear that the answer is "no",
but that hasn't dissuaded certain people from lobbying for us to do it
anyway.

As you say, the current implementation has a number of advantages that
"reread the original query string" would not --- including compliance to
the standard on the above point --- and I doubt we're going to want to
give those up. So a patch that has ambitions of getting accepted is
going to have to do something smarter. Don't know exactly what.

regards, tom lane