Stephen Frost <sfr...@snowman.net> wrote: > On Friday, September 20, 2013, Kevin Grittner wrote: >> Stephen Frost <sfr...@snowman.net> wrote: >> >>> The issue here is that we're trying to make the mat view look >>> like what the query would do when run at the same time, which >>> is a bit of a losing battle, imv. >> >> If we're not doing that, I don't see the point of matviews. > > When taken out of context, I can see how that might not come > across correctly. I was merely pointing out that it's a losing > battle in the context of types which have equality operators > which claim equalness but cast to text with results that don't > match there.
I think the patch I've submitted wins that battle. The only oddity is that if someone uses a query for a matview which can provide results with rows which are equal to previous result rows under the default record opclass but different under this patch's opclass, RMVC could update to the latest query results when someone thinks that might not be necessary. Workarounds would include using a query with deterministic results (like using the upper() or lower() function on a grouped citext column in the result set) or not using the CONCURRENTLY option. Neither seems too onerous. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers