Re: Display of multi-target-table Modify plan nodes in EXPLAIN

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: hlinnaka <hlinnaka(at)iki(dot)fi>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Display of multi-target-table Modify plan nodes in EXPLAIN
Date: 2015-03-23 14:59:18
Message-ID: CA+TgmoZG6GxrNqKnEbAK3dMHjTwWsWowvFZFyZiDp272rgxd7A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Mar 23, 2015 at 10:26 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Heikki Linnakangas <hlinnaka(at)iki(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kevin Grittner 2015-03-23 15:02:02 Re: Superuser connect during smart shutdown
Previous Message Andres Freund 2015-03-23 14:53:04 Re: "snapshot too large" error when initializing logical replication (9.4)