Re: Materialized views don't show up in information_schema

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.

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company