Re: MV patch broke users of ExplainOneQuery_hook

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