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 logicallyMulti-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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
