* Robert Haas (robertmhaas@gmail.com) wrote:
> On Tue, Sep 24, 2013 at 12:00 PM, Stephen Frost <sfrost@snowman.net> wrote:
> > It wouldn't address my concerns anyway, which are around these binary
> > operators and the update-in-place approach being risky and setting us up
> > for problems down the road.
>
> I think that if you want to hold up a bug fix to a feature that's
> already committed, you need to be more specific than to say that there
> might be problems down the road.
Committed isn't released and I simply can't agree that introducing new
operators is a 'bug fix'. Had it gone out as-is, I can't see us
back-patching a bunch of new operators to fix it.
> Note that, after we change the data in the underlying table, the
> output of the query changes. But REFRESH MATERIALIZED VIEW
> CONCURRENTLY doesn't fix it. However, REFRESH MATERIALIZED VIEW
> without CONCURRENTLY does fix it. That's a bug, because if there are
> two ways of refreshing a materialized view they should both produce
> the same answer. Shouldn't they?
The same queries run over time without changes to the underlying data
really should return the same data, shoudln't they? Is it a bug that
they don't?
In general, I agree that they should produce the same results, as should
incrementally maintained views when they happen. I'm not convinced that
choosing whatever the 'new' value is to represent the value in the
matview for the equal-but-not-binary-identical will always be the
correct answer though.
> The fact that users can write
> queries that don't always give the same answer is not a reason why
> it's OK for REFRESH CONCURRENTLY to misbehave on queries that do.
This really is, imv, agreeing to hold a higher standard for matviews
than we do for what matviews are *based* on- which is queries.
Thanks,
Stephen