Re: Materialized views don't show up in information_schema

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Fri, Oct 17, 2014 at 8:10 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > * Peter Eisentraut (peter_e(at)gmx(dot)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