Andres Freund <andres@2ndquadrant.com> wrote:
> If matview refreshs weren't using plain SQL and thus wouldn't
> require exposing that operator to SQL I wouldn't have a problem
> with this...
If RMVC were the end of the story, it might be worth building up a
mass of execution nodes directly, although it would be hard to see
how we could make the right planning choices (e.g., MergeJoin
versus HashJoin) that way. But the whole incremental maintenance
area, to have any chance of working accurately and without an
endless stream of bugs, needs to be based on relational algebra.
There needs to be a way to express that in a much higher level
language than execution node creation. If it doesn't use SQL we
would need to invent a relational language very much like it, which
would be silly when we have a perfectly good language we can
already use. The sky is blue; let's move on.
The test for identical records will be needed in SQL if we want to
have these matview features. We could limit use of that to
contexts where MatViewIncrementalMaintenanceIsEnabled(), but I
don't see the point. If someone uses an undocumented operator, and
uses it inappropriately, they may get a surprising result. We
already have undocumented operators to support record comparison
and pattern opclasses, and if people use those they may get
surprising results. I don't recall any reports of problems from
people actually trying to do so.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
