Nicolas Barbier wrote
> 2014-10-16 Stephen Frost <
> sfrost@
> >:
>
>> Alright, coming back to this, I have to ask- how are matviews different
>> from views from the SQL standard's perspective?
>
> Matviews that are always up to date when you access them are
> semantically exactly the same as normal views. Matviews that can get
> out of date, however, are not.
Materialized Views share features and properties of both tables and views -
and omit capabilities available to both as well. The performance
optimization spoken of is basically the table aspect of the feature while
the backing query makes it look like a view. But all the while it is a
distinct feature and one not described in the SQL standard.
From a read-only perspective I can see the value of having this particular
row-source available in the standard information schema but anything trying
to manipulate a matview as either a view or a table will be surprised.
Since the standard doesn't distinguish between read and write aspects of the
object types there isn't a safe way to add matviews to the information
schema that doesn't violate the intent of the provided view. If the
application/users wants to support/use PostgreSQL specific features it/they
have to be ready and able to use the catalog.
David J.
--
View this message in context:
http://postgresql.1045698.n5.nabble.com/Materialized-views-don-t-show-up-in-information-schema-tp5822643p5823379.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.