Re: generic explain options v3 - Mailing list pgsql-hackers

From Tom Lane
Subject Re: generic explain options v3
Date
Msg-id 17756.1248365300@sss.pgh.pa.us
Whole thread Raw
In response to Re: generic explain options v3  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: generic explain options v3
List pgsql-hackers
Robert Haas <robertmhaas@gmail.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.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Determining client_encoding from client locale
Next
From: Andrew Dunstan
Date:
Subject: Re: Extensions User Design