From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Kevin Grittner <kgrittn(at)ymail(dot)com> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: MV patch broke users of ExplainOneQuery_hook |
Date: | 2013-04-09 17:28:26 |
Message-ID: | 4729.1365528506@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
I wrote:
> Kevin Grittner <kgrittn(at)ymail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2013-04-09 17:30:38 | Re: page 1 of relation global/11787 was uninitialized |
Previous Message | Stephen R. van den Berg | 2013-04-09 17:27:59 | Re: page 1 of relation global/11787 was uninitialized |