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
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... |