From: | Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com> |
---|---|
To: | Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: SQL/MED - file_fdw |
Date: | 2011-01-21 13:59:33 |
Message-ID: | AANLkTi=U3pCeWR1J3rGG_EKqMY08PWVctee3-XaOhh+a@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Jan 21, 2011 at 22:12, Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)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 :)
--
Itagaki Takahiro
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-21 14:05:57 | Re: sepgsql contrib module |
Previous Message | Vick Khera | 2011-01-21 13:46:51 | Re: Large object corruption during 'piped' pg_restore |