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"?
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? If not, how do you justify it?
If so, how do you implement it (v1 has already got its pg_attribute
rows)?
Messy any way you look at it, I fear. But clearly my idea needs
more thought ...
regards, tom lane