Re: Adding columns to a view
От | Florian G. Pflug |
---|---|
Тема | Re: Adding columns to a view |
Дата | |
Msg-id | 43B1F304.2050504@phlo.org обсуждение исходный текст |
Ответ на | Adding columns to a view (Ingo van Lil <ingo@vanlil.de>) |
Ответы |
Re: Adding columns to a view
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: