Re: POSS. FEATURE REQ: "Dynamic" Views - Mailing list pgsql-general

From Greg Stark
Subject Re: POSS. FEATURE REQ: "Dynamic" Views
Date
Msg-id 873bov8a7i.fsf@stark.xeocode.com
Whole thread Raw
In response to Re: POSS. FEATURE REQ: "Dynamic" Views  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: POSS. FEATURE REQ: "Dynamic" Views  (Jeffrey Melloy <jmelloy@visualdistortion.org>)
List 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 by date:

Previous
From: Simrin Grewal
Date:
Subject: An update rule affecting an after insert trigger
Next
From: Mike Nolan
Date:
Subject: Dumb question about 8.1 beta test