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. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
