On Sat, May 21, 2016 at 10:32 AM, Euler Taveira <eu...@timbira.com.br>

> 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

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.

David J.

Reply via email to