Re: SQL/MED - file_fdw
От | Itagaki Takahiro |
---|---|
Тема | Re: SQL/MED - file_fdw |
Дата | |
Msg-id | AANLkTi=U3pCeWR1J3rGG_EKqMY08PWVctee3-XaOhh+a@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: SQL/MED - file_fdw (Shigeru HANADA <hanada@metrosystems.co.jp>) |
Ответы |
Re: SQL/MED - file_fdw
|
Список | pgsql-hackers |
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 :) -- Itagaki Takahiro
В списке pgsql-hackers по дате отправления: