On Tue, Mar 18, 2025 at 9:58 AM Andrei Lepikhov <lepihov@gmail.com> wrote:
> I agree with him, too. But, as you can see, I proposed not changing the
> first string or adding something there but just putting extension data
> under that line. Extra information about workers' state (not so
> important most of the time, I should say) sometimes makes it difficult
> to read.
OK, I wasn't sure if you meant just before or just after emitting the
end-of-first-line newline.
If you mean just after, that would amount to deciding that information
coming from extensions goes before information from core rather than
after. I thought about that and it's defensible, but in the end I
thought it made more sense for core info to come first. We could
bikeshed this endlessly, but there's no single choice that's going to
make everybody 100% happy, and adding a whole bunch of extra hooks to
cater to various preferences about exactly how the output should look
does not seem worth it to me.
> > I've committed 0001 and 0002 for now. The additional hook for
> > cross-option validation can be added in a separate commit. v6-0003,
> > now v7-0001, needs more substantive review before commit. I hope it
> > gets some, and soon.
> Ok, I am ready to review it thoroughly, if needed.
Yeah, I don't know if Tom is going to jump in here, but if we want to
get something into this release we don't have much time. I personally
think this is good enough that it would be better to have it than
nothing and we can always change stuff later. I'm not going to be too
sympathetic if somebody complains about a backward compatibility break
for pg_overexplain; it's labelled as a developer tool that shows
information about internals. That said, I don't want to ship something
and then have everybody say "what is this trash?".
--
Robert Haas
EDB: http://www.enterprisedb.com
