Re: record identical operator
От | Kevin Grittner |
---|---|
Тема | Re: record identical operator |
Дата | |
Msg-id | 1379244908.4881.YahooMailNeo@web162904.mail.bf1.yahoo.com обсуждение исходный текст |
Ответ на | Re: record identical operator (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: record identical operator
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: