Re: idea: storing view source in system catalogs

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: idea: storing view source in system catalogs
Дата
Msg-id 603c8f070805211933k3a46a7f7p6b0366c0d21de52@mail.gmail.com
обсуждение исходный текст
Ответ на Re: idea: storing view source in system catalogs  (David Fetter <david@fetter.org>)
Ответы Re: idea: storing view source in system catalogs  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: idea: storing view source in system catalogs  (Bruce Momjian <bruce@momjian.us>)
Список pgsql-hackers
I think the real problem here is that PostgreSQL is very finicky about
what operations you can perform on a view.  If I have a table foo and
I define a view bar that uses foo and a view baz that uses bar, I can
add a column to foo without a problem, and, similarly, I can also drop
or alter a column in foo that is not used by bar.  But the same is not
true of bar.  I can't make any changes at all to bar without dropping
and recreating it, and that means I have to drop and recreate baz as
well.  If there are only two views involved, this is not so bad, but
frequently there are a whole slough of views baz1, baz2, ..., bazn
that all depend on bar, and I have to drop and recreate every single
one of them.

I could understand the need to do this if I were (for example)
changing the type of some column that was used by all of these views,
but that's usually not the case.  Normally I'm just adding new columns
to foo and bar, and none of the other views are changing... but they
have to be recreated anyway.

As a side note, handling this problem gracefully would go a long way
to solving the original poster's concern about *-expansion. If
updating to the latest version of "*" just required re-executing
CREATE OR REPLACE VIEW ..., it would be relatively simple.  As things
stand now, it requires DROP VIEW ... CASCADE; CREATE OR REPLACE VIEW
...; followed by recreating all of the dependent objects.

...Robert


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andreas 'ads' Scherbaum
Дата:
Сообщение: Re: triggers on prepare, commit, rollback... ?
Следующее
От: "Pavel Stehule"
Дата:
Сообщение: why SPI_execute_with_args don't use known values for optimalisation