Re: generic explain options v3

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

On Thu, Jul 23, 2009 at 12:08 PM, Tom Lane<tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> Ugh.  I took a look at this and it turns out that there are some
>> tentacles.  It doesn't seem very sane to actually do anything with a
>> list of DefElem nodes, so we really need to parse that list and
>> convert it to a more sensible format right away (this also seems
>> important for proper error checking).
>
> Yeah, the standard approach is to convert it into a group of values
> at the start of execution of the utility command.
>
>> The obvious solution to that is to create the ExplainState sooner,
>> back up at the ExplainQuery level.  If we do that, though, then
>> ExplainState will need to become a public API, because
>> contrib/auto_explain calls ExplainPrintPlan().
>
> Well, if we add any more options to EXPLAIN then auto_explain may well
> be interested in them, so I'm not sure this is bad.  The alternative
> is to keep adding retail parameters to the public functions.
>
>> And if we do that,
>> then probably we should declare it in include/nodes/execnodes.h and
>> make it a node type...
>
> No, just a struct declared in commands/explain.h.  There's no reason
> for it to be part of the Node system.

Oh, OK. That will work. Thanks.

...Robert

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2009-07-23 18:24:43 Re: Determining client_encoding from client locale
Previous Message Tom Lane 2009-07-23 18:16:59 Re: join regression failure on cygwin