Re: SQL/MED - file_fdw

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>
Cc: Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SQL/MED - file_fdw
Date: 2011-01-21 14:27:09
Message-ID: AANLkTimzEaFi1wpH+G7jdvkAzL6c15ZomR1ghRT6Wejd@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jan 21, 2011 at 8:59 AM, Itagaki Takahiro
<itagaki(dot)takahiro(at)gmail(dot)com> wrote:
> 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 :)

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-01-21 14:39:03 More detailed auth info
Previous Message Robert Haas 2011-01-21 14:05:57 Re: sepgsql contrib module