Re: POSS. FEATURE REQ: "Dynamic" Views

Поиск
Список
Период
Сортировка
От Greg Stark
Тема Re: POSS. FEATURE REQ: "Dynamic" Views
Дата
Msg-id 873bov8a7i.fsf@stark.xeocode.com
обсуждение исходный текст
Ответ на Re: POSS. FEATURE REQ: "Dynamic" Views  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: POSS. FEATURE REQ: "Dynamic" Views  (Jeffrey Melloy <jmelloy@visualdistortion.org>)
Список pgsql-general
Bruce Momjian <pgman@candle.pha.pa.us> writes:

> Well, I just added to TODO:
>
>     * Allow VIEW/RULE recompilation when the underlying tables change
>
> Is dynamic view a industry-standard name?  If so, I will add it to the
> TODO.

"DYNAMIC" is something I made up.

"ALTER VIEW RECOMPILE" is Oraclese but I'm not sure what we're talking about
here is exactly the same purpose. I'm not sure it even does anything in Oracle
any more. It used to be that *any* DDL on underlying tables caused view on
them to become invalid and produce errors until they were recompiled. I think
that's changed and "recompile" may be a noop now on Oracle.

>
> Updated TODO is:
>
>     * Allow VIEW/RULE recompilation when the underlying tables change
>
>       Another issue is whether underlying table changes should be reflected
>       in the view, e.g. should SELECT * show additional columns if they
>       are added after the view is created.

I think we're 100% certain that it should not do this by default. The spec
requires it. What's unknown is whether there should be an option to do it
automatically. In my humble opinion there's no downside to having a facility
for users to do it manually though.

Hence why I separated it into three points:

> > o Add warning whenever DDL to a table affects a view dependent on that table.
> >   Such as when a column is altered that is referenced in the view or when a
> >   column is added if a "select *" appears in the view.
> >
> > o Add some option to CREATE VIEW to cause the above ALTER VIEW RECOMPILE to
> >   automatically happen whenever DDL to a table affects the view.
> >
> > I think the first of these two are no-brainers if they're implemented well.
> > The third seems less likely to garner immediate support.

--
greg

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

Предыдущее
От: Simrin Grewal
Дата:
Сообщение: An update rule affecting an after insert trigger
Следующее
От: Mike Nolan
Дата:
Сообщение: Dumb question about 8.1 beta test