Sorry if I offended you.I wasn't offended because I wasn't sure what you wanted to say to me. You may call me the biggest fool of all, as long you do it in Sualheli, or Korean... :-)
Yes, that's right. I've been working this way for years, and all MSSQL users do because there's no other way for them.'You what!' is what you say when you cannot believe what someone is saying... Calling 'stable views that work when you rename columns' a gimmick is quite an incredible thing to say...
You honestly would rather be able to view accurate source of views that don't work rather than complicted source of views that actually work?
These automatic name change propagation is very limited, concerning all possible changes you can have in a table.
- drop column -> will restrict now, or need cascade
- rename column -> propagates to plan tree, why not restrict or require cascaded to drop source?
- alter column size/type -> not possible, need to create alternate column, drop old (which is restricted...) and rename
You see, only few changes that can be done are handled at the moment.
In my experience with large and complicated data models, I found that I hardly ever would rename a table or a column. There's nothing like an automatic column name update of applications... After years, it's hard to tell where everything's used, especially if queries are created at runtime.
I consider a view more as being a part of an application, rather than part of the data model (unless rules are used), and thus the same problems apply.
What I need again and again, is changing the size of a column (rarely the type). For pgsql, I'd have to drop the column, and need to recreate all views. For MSSQL, it won't matter if the column is dropped/recreated or just resized, the view won't notice until it's used again.
Anyway, there's no reason why we can't have both with a bit of effort...This certainly would be nice, maybe there could be back-pointers from nodes into the source so identifier names can be identified and modified? Just like debugging-enabled code has references to the source.
Another way could be storing the source in a translated form, like SELECT X.($88012.1) FROM $88012 AS X instead of SELECT X.bar FROM public.foo AS X
Regards, Andreas
---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
