Re: Rule recompilation

Tom Lane wrote:
> 
> Hiroshi Inoue <Inoue@tpf.co.jp> writes:
> > We would have to reconsider *alter table .. rename ..* ..
> 
> Yeah, that's one thing that would act differently if we adopt my idea of
> considering the source text of the rule to be the primary definition.
> It's not clear if this is good or bad, however.  Consider:
> 
>         create table foo (f1 int, f2 text);
> 
>         create view v1 as select f1 from foo;
> 
>         alter table foo rename column f1 to fx;
> 
>         alter table foo rename column f2 to f1;
> 
> At this point, what would you expect v1 to return, and why?  How
> would you justify it in terms of "what the user would expect",
> as opposed to "what we can conveniently implement"?
> 

The view v1 is INVALIDated by the first ALTER command.
It is still INVALID after the second ALTER command.
When *select * from v1* is called, the re-compilation 
would translate it into *select f1(originally f2) from foo*.
The behavior is different from that the current.
The current *reference by id* approach is suitable
for the current *rename* behavior but *reference by
name* approach isn't. *rename* isn't that easy from
the first IMHO.

> Another interesting case is:
> 
>         create table foo (f1 int, f2 text);
> 
>         create view v1 as select * from foo;
> 
>         alter table foo add column f3 float;
> 
> Should v1 now have three columns? 

Yes. We could create the view v1 as *select f1, f2 
from foo* from the first if we hate the side effect. 

> If not, how do you justify it?
> If so, how do you implement it (v1 has already got its pg_attribute
> rows)?
> 

Isn't the creation of pg_attribute tuples a part of
(re-)compilation ?

regards,
Hiroshi Inoue