Re: Materialized views don't show up in information_schema

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