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
whichit gets the MV definition from... Although having said that, if you went down the route you suggest, would not you
makethat “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
desirableto “stack” MVs upon each other. (I’m not immediately sure whether such a use case is still needed in face of
analways-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
textas SQL?), and I do agree — that’s probably the right direction... it does seem to me there is scope to leverage the
“bottomhalf” of the ASSERTION stuff from Dave Fetter that Corey linked to — i.e., the part of it that manages triggers.
Stillleaves the AST crawling deciding what to actually do once a change is caught.
Really good to hear about progress in this area.
d.