> That is expected because AccessExclusiveLock is acquired on the existing
> matview. This is also the case for CREATE OR REPLACE VIEW.
Right, had this case many times.
>
> My initial idea, while writing the patch, was that one could replace the
> matview without populating it and then run the concurrent refresh, like
> this:
>
> CREATE OR REPLACE MATERIALIZED VIEW foo AS ... WITH NO DATA;
> REFRESH MATERIALIZED VIEW CONCURRENTLY foo;
>
> But that won't work because concurrent refresh requires an already
> populated matview.
>
> Right now the patch either populates the replaced matview or leaves it
> in an unscannable state. Technically, it's also possible to skip the
> refresh and leave the old data in place, perhaps by specifying
> WITH *OLD* DATA. New columns would just be null. Of course you can't
> tell if you got stale data without knowing how the matview was replaced.
> Thoughts?
I believe the expectation is to get materialized views updated whenever
it gets replaced so likely to confuse users ?
