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-23 16:08:20 |
Message-ID: | 17756.1248365300@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:
> 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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2009-07-23 16:09:07 | Re: Extensions User Design |
Previous Message | Tom Lane | 2009-07-23 16:02:24 | Re: Determining client_encoding from client locale |