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