Re: MV patch broke users of ExplainOneQuery_hook - Mailing list pgsql-hackers

From Tom Lane
Subject Re: MV patch broke users of ExplainOneQuery_hook
Date
Msg-id 4729.1365528506@sss.pgh.pa.us
Whole thread Raw
In response to Re: MV patch broke users of ExplainOneQuery_hook  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: MV patch broke users of ExplainOneQuery_hook
List pgsql-hackers
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 --- had my head in trigram regex stuff all
> weekend.  Gimme a couple hours ...

[ 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.

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.
        regards, tom lane



pgsql-hackers by date:

Previous
From: "Stephen R. van den Berg"
Date:
Subject: Re: page 1 of relation global/11787 was uninitialized
Next
From: Andres Freund
Date:
Subject: Re: page 1 of relation global/11787 was uninitialized