(2014/12/07 2:02), David Fetter wrote:
> On Thu, Dec 04, 2014 at 12:35:54PM +0900, Etsuro Fujita wrote:
>> But I think
>> there would be another idea. An example will be shown below. We show the
>> update commands below the ModifyTable node, not above the corresponding
>> ForeignScan nodes, so maybe less confusing. If there are no objections of
>> you and others, I'll update the patch this way.
>>
>> postgres=# explain verbose update parent set a = a * 2 where a = 5;
>> QUERY PLAN
>> -------------------------------------------------------------------------------------
>> Update on public.parent (cost=0.00..280.77 rows=25 width=10)
>> On public.ft1
>> Remote SQL: UPDATE public.mytable_1 SET a = $2 WHERE ctid = $1
> ^^^^^^^^^^
> It occurs to me that the command generated by the FDW might well not
> be SQL at all, as is the case with file_fdw and anything else that
> talks to a NoSQL engine.
>
> Would it be reasonable to call this "Remote command" or something
> similarly generic?
Yeah, but I'd like to propose that this line is shown by the FDW API
(ie, ExplainForeignModify) as in non-inherited update cases, so that the
FDW developer can choose the right name. As for "On public.ft1", I'd
like to propose that the FDW API also show that by calling a function
for that introduced into the PG core (Would it be better to use "For"
rather than "On"?).
Sorry, my explanation was not enough.
Best regards,
Etsuro Fujita
