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
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) |