On Sat, 2005-08-27 at 09:48, Tom Lane wrote:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >> How is this different from materialized views, which is already on the
> >> TODO list?
>
> > The idea behind the DYNAMIC VIEW is that if you made a DDL change in the
> > table it could be reflected in th
Greg Stark wrote:
Bruce Momjian 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 O
My first idea when this was mentioned was more like
ALTER TABLE CASCADE
where CASCADE meant recompile all the views that depend on that table.
Not that I think any of this is a good idea, but if it was going to be
done, that's what would make the most sense to me.
- Ian
-
Greg Stark wrote:
Tom Lane <[EMAIL PROTECTED]> writes:
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
How is this different from materialized views, which is already on the
TODO list?
The idea behind the DYNAMIC VIEW is that if you made a DDL change in the
table it could be refl
Tom Lane <[EMAIL PROTECTED]> writes:
> "Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> >> How is this different from materialized views, which is already on the
> >> TODO list?
>
> > The idea behind the DYNAMIC VIEW is that if you made a DDL change in the
> > table it could be reflected in the view.
Bruce Momjian 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 s
Tom Lane wrote:
But why exactly is this a good idea?
Especially since it seems one could write PLPGSQL functions to emulate
this if it was so important. The lack of PLPGSQL functions to do this
seems to indicate that it is not worth the trouble,
It is oft-repeated advice that you don't
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
>> How is this different from materialized views, which is already on the
>> TODO list?
> The idea behind the DYNAMIC VIEW is that if you made a DDL change in the
> table it could be reflected in the view. So for example, if you defined
> a view as SELECT
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.
Updated TODO is:
* Allow VIEW/RULE recompilation when the underlying tables change
Bruce Momjian writes:
> How is this different from materialized views, which is already on the
> TODO list?
It's entirely unrelated.
Materialized views are about having all the data stored in advance. They're
really tables that have some sort of process to keep the data in them in sync
with ot
On Sat, Aug 27, 2005 at 12:50:44AM -0400, Bruce Momjian wrote:
> Jim C. Nasby wrote:
> > > I wonder whether it would be saleable to have an option to work around
> > > this
> > > "feature". I'm thinking one of two directions:
> > >
> > > 1) An alternate type of view that just stores the text of t
Jim C. Nasby wrote:
> > I wonder whether it would be saleable to have an option to work around this
> > "feature". I'm thinking one of two directions:
> >
> > 1) An alternate type of view that just stores the text of the view and is
> > interpreted at time of use like:
> >
> > CREATE DYNAMIC VIEW
On Fri, Aug 26, 2005 at 04:54:06PM -0400, Greg Stark wrote:
>
> Ian Harding <[EMAIL PROTECTED]> writes:
>
> > Brand X doesn't do it in their backend either.
>
> If your Brand X is the same as my Brand X then it's worth noting that they
> didn't previously do anything sane in their backend. It us
Ian Harding <[EMAIL PROTECTED]> writes:
> Brand X doesn't do it in their backend either.
If your Brand X is the same as my Brand X then it's worth noting that they
didn't previously do anything sane in their backend. It used to invalidate all
your views and you had to recompile them before they
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> ... since currently CREATE VIEW v AS SELECT * FROM t
> actually expands the * out at creation time.
I believe that that behavior is required by the SQL spec. For instance,
SQL92's description of ALTER TABLE ADD COLUMN sez:
Note: The additi
Brand X simulates this in their GUI diagrammer by tracking
dependencies and dropping and recreating dependent views on schema
changes. This might be a better job for one of the GUI tools for us
too, rather than trying to put it in the back end. Brand X doesn't do
it in their backend either.
On
On Thu, Aug 25, 2005 at 03:03:30PM -0700, CSN wrote:
> For lack of a better term, but I was curious if there
> is/was any thought about making PG's views
> automatically "see" changes in underlying tables, as
> opposed to currently having to drop/create all
> corresponding views if a table's struct
For lack of a better term, but I was curious if there
is/was any thought about making PG's views
automatically "see" changes in underlying tables, as
opposed to currently having to drop/create all
corresponding views if a table's structure (add/delete
fields, etc.) is changed.
CSN
18 matches
Mail list logo
