On 20-05-2016 20:34, Robert Haas wrote: > Hmm, my experience is different. I use EXPLAIN (ANALYZE, VERBOSE) a > lot, but EXPLAIN (ANALYZE, BUFFERS) only rarely. I wonder if a GUC is > the way to go. > I wouldn't like a command output controlled by GUC. EXPLAIN is used a lot in bug/performance reports.
And most of the time the choice of options is totally arbitrary based upon the mood and experience of the user, so what's it matter if they saved a few keystrokes and set the GUC in the .psqlrc file?
I'm predicting users that will have trouble while using EXPLAIN if someone change the suggested GUC. It also breaks clients/applications that parse EXPLAIN.
Pretty much the same argument as above.
I would not expect a DBA to set this value globally - but shame on them if they do. I'd expect either ALTER ROLE or SET usage, in .psqlrc if applicable, to be the dominate usage for setting the value to a non-empty string. There is UI to consider here but I don't see any fundamental problems.
I don't want another bytea_output. However, if someone wants to suggest turning on/off some option defaults, I'm all ears.
I don't see the resemblance. There was, and is, no way to change the output format of bytea within the SELECT SQL statement, only the via GUC. But with explain everything you could do with the GUC can and is already being done by people simply tossing or excluding options on the EXPLAIN SQL statement they write.
All this does is allow the user to setup their preferred defaults in said GUC so they don't have to keep typing them in over and over again. If the GUC results in a broken output in whatever context you care about the user doing it manually would have the same result.
