Tom Lane <tgl@sss.pgh.pa.us> wrote:
> I wrote:
>> Kevin Grittner <kgrittn@ymail.com> writes:
>>> Any objections to my pushing the patch I posted Friday to draw a
>>> distinction between populated and scannable, which also attempted
>>> to address a couple points raised by you, or would you rather the
>>> code didn't change at the moment?
>
>> I didn't look at it yet
> [ looks... ] TBH, most of that code is code that I'd like to see
> removed, not just renamed; I do not think its problems are primarily
> cosmetic. However I have no objection to pushing what you have for
> the moment. Perhaps clarifying the intent will help us think about
> where to go from here.
My hope is that it will do that at a minimum. Thanks for looking
at this, BTW.
> One point that does come to mind, though, as long as you're trying
> to draw a distinction between "populated" and "scannable", is why
> pg_dump should be paying attention to one or the other; or indeed
> why it should care about the matviews' current contents at all.
> It seems to me that it would be more useful to not pay any attention
> to that, but instead have a command-line switch to control whether
> the dump includes commands to repopulate matviews or not. Driving
> this off the current state seems rather akin to expecting pg_dump
> to reproduce the contents of indexes exactly, rather than build
> them from scratch.
I guess my thinking was that without that you might dump and
restore and have a database which is not usable without further
work (if the matview data is needed for correct operation) or you
might populate a matview which was not yet intended to *be*
populated. I'm not tied to that, but it seemed reasonable and
likely to be useful. It's going to be hard to sell me that by
default a materialized view which has not been populated should
quietly behaves as though empty or should execute the underlying
query as though it were a "normal" view -- those seem like
correctness issues to me; but behavior for pg_dump seems less
definite.
--
Kevin Grittner
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company