Re: FDW API: don't like the EXPLAIN mechanism

From: Andrew Dunstan <andrew(at)dunslane(dot)net>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Shigeru HANADA <hanada(at)metrosystems(dot)co(dot)jp>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: FDW API: don't like the EXPLAIN mechanism
Date: 2011-02-21 16:11:25
Message-ID: 4D628EAD.4040708@dunslane.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 02/19/2011 11:07 PM, Tom Lane wrote:
>
> However, it occurs to me that as long as we're passing the function the
> ExplainState, it has what it needs to add arbitrary EXPLAIN result
> fields. Although it could do this the hard way, we could make it a lot
> easier by exporting the ExplainProperty<Type> functions. Then it'd be
> possible to produce output like
>
> Foreign Scan on public.agg_csv
> Foreign File: @abs_srcdir@/data/agg.csv
> Foreign File Size: 46
>
> which seems a whole lot nicer than the current design. In this scheme
> the callback function would just be declared to return void.
>
> Anybody have an objection to doing it like that?
>
>

If we allow the invention of new explain states we'll never be able to
publish an authoritative schema definition of the data. That's not
necessarily an argument against doing it, just something to be aware of.
Maybe we don't care about having EXPLAIN XML output validated.

cheers

andrew

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Thom Brown 2011-02-21 16:21:37 Re: SQL/MED - file_fdw
Previous Message Alvaro Herrera 2011-02-21 15:56:36 Re: Snapshot synchronization, again...