Re: Display of multi-target-table Modify plan nodes in EXPLAIN - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Display of multi-target-table Modify plan nodes in EXPLAIN
Date
Msg-id CA+TgmoZG6GxrNqKnEbAK3dMHjTwWsWowvFZFyZiDp272rgxd7A@mail.gmail.com
Whole thread Raw
In response to Re: Display of multi-target-table Modify plan nodes in EXPLAIN  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Mon, Mar 23, 2015 at 10:26 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Heikki Linnakangas <hlinnaka@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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: "snapshot too large" error when initializing logical replication (9.4)
Next
From: Kevin Grittner
Date:
Subject: Re: Superuser connect during smart shutdown