On Thursday, May 19, 2016, David Christensen <da...@endpoint.com> wrote:

> > On May 19, 2016, at 3:17 PM, Евгений Шишкин <itparan...@gmail.com
> <javascript:;>> wrote:
> >
> >
> >> On 19 May 2016, at 22:59, Tom Lane <t...@sss.pgh.pa.us <javascript:;>>
> wrote:
> >>
> >> David Christensen <da...@endpoint.com <javascript:;>> writes:
> >>> This simple patch adds “ALL” as an EXPLAIN option as shorthand for
> >>
> >> I'm not sure this is well thought out.  It would mean for example that
> >> we could never implement EXPLAIN options that are mutually exclusive
> >> ... at least, not without having to redefine ALL as
> all-except-something.
> >> Non-boolean options would be problematic as well.
> >>
> >
> > Maybe EVERYTHING would be ok.
> > But it is kinda long word to type.
> If it’s just a terminology issue, what about EXPLAIN (*); already a
> precedent with SELECT * to mean “everything”.  (MAX?


> LIKE_I’M_5?) Let the bikeshedding begin!


> In any case, I think a shorthand for “give me the most possible detail
> without me having to lookup/type/remember the options” is a good tool.


EXPAIN ABCTV (might need permission to document this variation though)

The later has some resemblance to option short form in command lines.

The bigger question is do we want to solve this in the server or let it be
a client concern and stick some usability enhancements into psql?  Maybe
even put it in psql first then migrate to the server after some field

The middle road is probably something like the following:

We could setup a guc for "default_explain_options" that the user could set
or have set for them using alter role.  Maybe we'd want to include a new
option "CLEAN" or "NONE" that tells the system to skip those default and
only use ones that are explicitly specified in the SQL command.  Basically
an envvar like many command line apps use in lieu of an .rc file but with a
simpler way to disable than setting it to nothing.

David J.

Reply via email to