Stephen Frost <sfrost@snowman.net> wrote:
> On Friday, September 20, 2013, Kevin Grittner wrote:
>> Stephen Frost <sfrost@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
