Ingo van Lil wrote:
> Hi there,
>
> is there any way to add new columns to a view without dropping and
> recreating it (and thus every other view that depends on it)? A friend
> of mine came up with a crude hack that involves manipulating the reltype
> flag in pg_class so Postgres thinks the view is actualy a table, using
> 'ALTER TABLE' to add a new column, restoring the old reltype and
> changing the _RETURN rule for that view to include the new column as
> well. The existence of that "solution" lost me a bet and a crate of
> beer, but I wouldn't really want to use it in a production-stage
> database. ;-)
> I could think of a few situations where extending a view might be
> useful, and I'd appreciate to see it supported. I don't see any reason
> not to allow it as long as no existing columns are removed or have their
> type changed.
Well, some other view could do "select * from <firstview>", or some
client code could assume a certain number of rows, and missbehave
if there are more rows...
But of course some other client code could also depend on
getting a sorted result-set, but still an order-by clause _can_
be remove.
If I need to change the order or number of columns in a view,
I use pgadmin to find the dependent objects, copy their
definitions into a sql-window (including the "drop ... " line),
put my new definition and a "drop cascade " in front, and execute
all that inside a transaction. But you're right, if more then
5 or so other objects depend on a view, this gets pretty annyoing..
greetings, Florian Pflug
