Definitely far from production quality IMO, but I think interesting enough to be included. I'll have to think over what would happen in each of the scenarios you presented above, but it's definitely not very robust at this point. Some more test cases clarifying the current behaviour are definitely in order.
That said, I've tried to make the rule fairly restrictive so it won't try to rewrite cases that aren't correctly handled. For example, I check that all the joins are inner joins. My target for this is conjunctive queries with equality predicates and simple field references in the SELECT clause.
Or if the the MV doesn't use any table twice, but the MV does?
I assume one of the references to MV above should be query?
I haven't thought specifically about the complexity of this approach, but I would expect poor performance with a large number of MVs. The paper gives some ideas on how to build index structures to optimize this. On a related note, if you have any suggestions on where an appropriate place in the code would be to construct such indexes and what object should own the index data, that would be helpful.
As for where this fits into planning, I think this could still work as part of Volcano. Using MVs when possible is not always the best choice. It also enables cost-based selection of multiple MVs when that's an option.
Thanks for the style suggestions. I fixed those issues.