Re: generic explain options v3
От | Tom Lane |
---|---|
Тема | Re: generic explain options v3 |
Дата | |
Msg-id | 17756.1248365300@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: generic explain options v3 (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: generic explain options v3
|
Список | 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 по дате отправления: