Tom has refactored where and how certain parts of the work get done for materialized views, reducing issues with modularity violations. I have been and will continue to review his changes to better understand how the pieces of the code fit together, so hopefully he won't need to do so much with future contributions. He has not, so far, changed functionality or the regression tests -- although he has complained about things, of which the below is the all of what remains as an issue for him as far as I know. I may have missed something; if so, it would be great to be reminded of what.
What remains is a choice between three alternatives on which no consensus has been reached. There are three things that, as fas as I can tell, *everyone* agrees would be nice to be true about the matview implementation for 9.3, but it does not seem feasible to have more than two: (1) The ability to count on the results from a query which references a matview to reflect valid data from *some* point in time. (2) The ability to create unlogged materialized views. (3) The ability to consider a zero-length matview heap and a matview heap with allocated-but-empty pages as logically identical. Tom wants to ditch (2) to allow the others. Robert wants to ditch (1) to allow the others. I want to ditch (3) to allow the others. Andres wants (3) and has not expressed an opinion on which he would prefer to give up to get it. I believe Josh Berkus has mentioned how useful he thinks both (1) and (2) would be, without really commenting on (3). I am convinced that we can solve (3) in a later release without any significant impact on those already using matviews, including unlogged ones. Tom and Robert have suggested that the current implementation would paint us into a corner or pose a pg_upgrade hazard, without any clear indication of the mechanism of the problem. The logjam has caused me to hold back on finishing up the direction I prefer, for fear of conflicts with other work that someone else may be trying to do. Given that time is short, I'm going to apply the patch which inserts five lines (two of them comment lines) on the basis that at least the way that is currently implemented will have no known bugs, and it's just not that much to rip back out if we reach consensus on another direction. How to we resolve this impasse? -- 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
