Dimitri Fontaine <dimitri@2ndQuadrant.fr> wrote:
> Kevin Grittner <kgrittn@ymail.com> writes:
>> The problem, as I see it, is that the view and the concurrently
>> refreshed materialized view don't yield the same results for the
>> same query. The rows are equal, but they are not the same.
>> With the patch the matview, after RMVC, looks just the same as
>> the view.
>
> My understanding is that if you choose citext then you don't care
> at all about the case
That's not my understanding. If that was what citext was for it
would be much simpler to force the case in creating each value. It
*preserves* the case for display, but ignores it for comparisons.
That's the contract of the type, like it or not. "Equal" does not
mean "the same". They clearly want to preserve and display
differences among equal values.
Streaming replication would preserve the differences. pg_dump and
restore of the data would preserve the differences. SELECTing the
data shows the differences. suppress_redundant_updates_trigger()
will not suppress an UPDATE setting an "equal" value unless it is
also *the same*. A normal VIEW shows the differences. RMV without
CONCURRENTLY will show the difference. I'm suggesting that RMVC
and the upcoming incremental update of matviews should join this
crowd.
A matview which is being refreshed with the CONCURRENTLY option, or
maintained by incremental maintenance should not look different
from a regular VIEW, and should not suddenly look completely
different after a non-concurrent REFRESH. If things are left that
way, people will quite justifiably feel that matviews are broken.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company