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

On Fri, Dec 18, 2009 at 10:39 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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.

I'm unconvinced that this is, as you would say, even mildly sane. I
don't think changing the type of a column in one table constitutes a
license to randomly reinterpret the semantics of views that reference
it. Suppose that we have functions foo(int) and bar(varchar).
Someone creates a view like this:

SELECT foo(x.x1) FROM x;

Next, they rename the function foo to bar. Now, they change the type
of x1 from integer to varchar. Do you REALLY want to now go grab the
other function? Because that sounds like an incredibly bad idea to
me. I think we have a consistent principle that views, foreign key
constraints, and all manner of objects generally within the database
are tied to a particular object rather than a particular name. I
think that's unquestionably a good decision, but even someone were to
feel otherwise, I don't see how you can argue that we would SOMETIMES
want to follow the object and OTHER TIMES the name.

Maybe you could make an argument for treating foo(x.x1) call as
foo(x.x1::integer) after the type of x.x1 gets changed, but even that
seems suspiciously like black magic.

...Robert