| From: | David Christensen <david(at)endpoint(dot)com> | 
|---|---|
| To: | Евгений Шишкин <itparanoia(at)gmail(dot)com> | 
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: [PATCH] Add EXPLAIN (ALL) shorthand | 
| Date: | 2016-05-19 20:33:50 | 
| Message-ID: | C591816B-492C-4A75-84BF-F242873AFD5F@endpoint.com | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | pgsql-hackers | 
> On May 19, 2016, at 3:17 PM, Евгений Шишкин <itparanoia(at)gmail(dot)com> wrote:
> 
> 
>> On 19 May 2016, at 22:59, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 
>> David Christensen <david(at)endpoint(dot)com> writes:
>>> This simple patch adds “ALL” as an EXPLAIN option as shorthand for “EXPLAIN (ANALYZE, VERBOSE, COSTS, TIMING, BUFFERS)” for usability.
>> 
>> 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.
David
--
David Christensen
End Point Corporation
david(at)endpoint(dot)com
785-727-1171
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andreas Karlsson | 2016-05-19 21:50:01 | Parallel safety tagging of extension functions | 
| Previous Message | Alvaro Herrera | 2016-05-19 20:26:22 | Re: [PATCH] Add EXPLAIN (ALL) shorthand |