On Mon, Mar 23, 2015 at 10:26 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Heikki Linnakangas <hlinn...@iki.fi> writes: >> 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 ... >>> 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. > > I think this is entirely wrong. The entire point of having those > machine-readable output formats was to let people write tools that would > process plans in some intelligent manner. Relocating where child plans of > a Modify appear in the data structure would certainly break any tool that > had any understanding of plan trees. Now, maybe there are no such tools, > but in that case the whole exercise in adding those formats was a waste of > time and we should rip them out. > > In any case, what I was suggesting here is only very marginally cleaner > than what got implemented, so it really doesn't seem to me to be worth > breaking backwards compatibility here, even if I bought the premise that > backwards compatibility of this output is of low priority.
I agree that we shouldn't break backward compatibility here for no particularly good reason, but I also think it would be fine to break it if the new output were a significant improvement. People who write tools that parse this output should, and I think do, understand that sometimes we'll make changes upstream and they'll need to adjust for it. We shouldn't do that on a whim, but we shouldn't let it stand in the way of progress, either. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers