Tom Lane wrote: > > Hiroshi Inoue <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://www.postgresql.org/search.mpl
