Re: generic explain options v3

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: generic explain options v3
Date: 2009-07-22 02:05:30
Message-ID: 8554.1248228330@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Jul 21, 2009 at 7:47 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Also, I'd suggest changing the ExplainStmt struct to have a list of
>> DefElem options instead of hard-wiring the option set at that level.

> What is the advantage of that?

Fewer places to change when you add a new option; in particular, not
copyfuncs or equalfuncs. Also, the way you are doing it is gratuitously
unlike every other command that has similar issues to deal with.
Everybody else parses their DefElem list at execution time. I think
you should have the legacy ANALYZE and VERBOSE syntax elements generate
DefElem list members that get examined at execution.

BTW, I see that your "explain refactoring" patch is marked ready
for committer, but is it actually sane to apply it before the other
two?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-07-22 02:29:45 Re: generic explain options v3
Previous Message Tom Lane 2009-07-22 01:32:09 Re: Higher TOAST compression.