* Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Oct 17, 2014 at 8:10 PM, Stephen Frost <sfr...@snowman.net> wrote: > > * Peter Eisentraut (pete...@gmx.net) wrote: > >> On 10/16/14 9:45 AM, Stephen Frost wrote: > >> > Alright, coming back to this, I have to ask- how are matviews different > >> > from views from the SQL standard's perspective? I tried looking through > >> > the standard to figure it out (and I admit that I probably missed > >> > something), but the only thing appears to be a statement in the standard > >> > that (paraphrased) "functions are run with the view is queried" and that > >> > strikes me as a relatively minor point.. > >> > >> To me, the main criterion is that you cannot DROP VIEW a materialized view. > > > > That is an entirely correctable situation. We don't require 'DROP > > UNLOGGED TABLE'. > > I think that's an inapposite comparison. The fact that a table is > unlogged is merely a property of the table; it does not change the > fact that it is a table. A materialized view, on the other hand, is > different kind of object from a view. This manifests itself the fact > that it's represented by a different relkind; and that different > syntax is used not only for DROP but also for COMMENT, ALTER VIEW, > SECURITY LABEL, and ALTER EXTENSION .. ADD/DROP; and that the set of > supported operations on a materialized view is different from a > regular view (and will probably be more different in the future). If > we really want to change this, we can't just change DROP VIEW; we need > to change all of the places in a consistent fashion, and we probably > have to continue to support the old syntax so that we don't break > existing dumps.
Yes, clearly we'd have to adjust the syntax for all of the commands to
support both with MATERIALIZED and without. I don't have an issue with
that. The argument makes more sense if there are operations which ONLY
work against a regular view and do *not* work against a matview.
Operations which operate only against a matview simply must have
MATERIALIZED used for them.
> But I think it's the wrong thing anyway, because it presumes that,
> when Kevin chose to make materialized views a different relkind and a
> different object type, rather than just a property of an object, he
> made the wrong call, and I don't agree with that. I think he got it
> exactly right. A materialized view is really much more like a table
> than a view: it has storage and can be vacuumed, clustered, analyzed,
> and so on. That's far more significant IMV than the difference
> between a table and unlogged table.
I don't think Kevin was wrong to use a different relkind, but I don't
buy into the argument that a different relkind means it's not a view.
As for the other comments, I agree that a matview is *more* than a view,
but at its base, in my view (pun intended), it's still a view. Why not
call it a materialized query?
Thanks,
Stephen
signature.asc
Description: Digital signature
