On Tue, Mar 18, 2025 at 9:58 AM Andrei Lepikhov <lepi...@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
