On Fri, Jan 21, 2011 at 8:59 AM, Itagaki Takahiro
<itagaki.takahiro@gmail.com> wrote:
> On Fri, Jan 21, 2011 at 22:12, Shigeru HANADA <hanada@metrosystems.co.jp> wrote:
>>> My concern is the explainInfo interface is not ideal for the purpose
>>> and therefore it will be unstable interface. If we support nested plans
>>> in FDWs, each FDW should receive a tree writer used internally in
>>> explain.c. explainInfo, that is a plan text, is not enough for complex
>>> FdwPlans. However, since we don't have any better solution for now,
>>> we could have the variable for 9.1. It's much better than nothing.
>>
>> When I was writing file_fdw, I hoped to use static functions in
>> explain.c such as ExplainProperty() to handle complex information.
>> Even for single plan node, I think that filename and size (currently
>> they are printed in a plain text together) should be separated in the
>> output of explain, especially when the format was XML or JSON.
>
> Just an idea -- we could return complex node trees with explainInfo
> if we use XML or JSON for the format. For example, pgsql_fdw can
> return the result from "EXPLAIN (FORMAT json)" without modification.
>
> It might be one of the reasons we should should support JSON in the core :)
Nice try, but I think that'd be a real drag. You wouldn't want to
return JSON when the explain format is text, or XML.
I think we probably need to modify the EXPLAIN code so that FDWs get a
chance to inject their own customer properties into the output, but I
don't know that we need to get that done right this minute. We can
ship something really crude/basic for 9.1, if need be, and fix this up
for 9.2. Of course if it turns out that getting EXPLAIN working the
way we'd like is really easy, then we can just do it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
