Hi Nico, I’m pretty impressed anything in this space can be written entirely in PlPGQSL!
If you did integrate your implementation, it would be easy for my Extension to read from a table other than the one which it gets the MV definition from... Although having said that, if you went down the route you suggest, would not you make that “regular table” into a first class scheme object very much like Corey’s CONTINUOUS MATERIALIZED VIEW object concept? It is interesting that you can put triggers onto the table though, as that leads well in to use cases where it is desirable to “stack” MVs upon each other. (I’m not immediately sure whether such a use case is still needed in face of an always-up-to-date MV feature such as is described, but I’ve seen it elsewhere.) You say you’d like to base it off a VIEW’s AST (rather than, I presume, you must parse the reconstructed VIEW source text as SQL?), and I do agree — that’s probably the right direction... it does seem to me there is scope to leverage the “bottom half” of the ASSERTION stuff from Dave Fetter that Corey linked to — i.e., the part of it that manages triggers. Still leaves the AST crawling deciding what to actually do once a change is caught. Really good to hear about progress in this area. d.
