On 03/22/2015 03:02 AM, Tom Lane wrote:
> In a green field we might choose to solve this by refactoring the output
> so that it's logically
>
> Multi-Table Update
> [
> Update Target: pt1
> Plan: (seq scan on pt1 here)
> ]
> [
> Update Target: ft1
> Remote SQL: UPDATE ref1 ...
> Plan: (foreign scan on ft1 here)
> ]
> [
> Update Target: ft2
> Remote SQL: UPDATE ref2 ...
> Plan: (foreign scan on ft2 here)
> ]
> [
> Update Target: child3
> Plan: (seq scan on child3 here)
> ]
The "Remote SQL" nodes should go under the Foreign Scan nodes.
> but I think that ship has sailed. Changing the logical structure of
> EXPLAIN output like this would break clients that know what's where in
> JSON/YAML/XML formats, which is exactly what we said we wouldn't do with
> those output formats.
If we have promised that, I think we should break the promise. No
application should depend on the details of EXPLAIN output, even if it's
in JSON/YAML/XML format. EXPLAIN is used by humans, and by tools like
pgAdmin that display the output for humans, so let's do what makes most
sense for humans. Admin tools will have to deal with new node types, and
also new plan structures in every new release anyway. And if an admin
tool doesn't recognize the new format, it surely falls back to
displaying them in some a reasonable generic form.
- Heikki