Tom Lane <t...@sss.pgh.pa.us> wrote: > In the interests of moving the discussion along, attached are > draft patches to show what I think we should do in 9.3. The > first patch disables the unlogged-matviews feature at the user > level (and perhaps could be reverted someday), while the second > one moves scannability-state storage into a pg_class column.
I'm going to submit a modified version of the second patch today. My biggest problems with it as it stands are the name chosen for the new pg_class column, and the hard-coded assumption that this relation-level flag is a good long-term indicator of whether all connections find a matview to be scannable. Scannability should be abstracted to allow easy addition of other factors as we add them. Whether or not the "populated" state is in the catalog, it is a serious mistake to conflate that with scannability. Scannability will always be influenced by whether the matview has been populated, but it is short-sighted not to draw a distinction now, so that work people do in their applications is does not have to be redone as we make scannability tests better. Not to mention the confusion factor of treating them as this patch does and then trying to properly draw the distinction later. IMV this patch, as it stands, does much more to paint us into a corner regarding future expansion than what came before. As one example, I think it is highly desirable, long term, to allow different sessions to set GUCs to different tolerances for old data, and thus have different perspectives on whether a matview is scannable; and this patch forces that to be the same for every session. The code I committed allows expansion in the direction of different session perspectives on scannability, and the suggested patch closes that door. -- Kevin Grittner EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
