Re: generic options for explain

Hi Robert,

On 05/24/2009 02:47 AM, Robert Haas wrote:
> Well, here we are! Yet another thread about some piece of information
> that's omitted from EXPLAIN and can't easily be added because there
> are a zillion things we want to add to EXPLAIN and it's not OK to bury
> the user[1]! I've long been of the opinion that the right way to fix
> this problem is to extend the syntax with some sort of extensible
> options syntax[2]. The current "EXPLAIN [ANALYZE] [VERBOSE]<query>"
> syntax does not scale to large numbers of options - it requires that
> the options occur in a fixed order, and that the option names all be
> keywords. Having gotten throughly fed up with having this
> conversation for the ump-teenth time, I wrote a patch to introduce
> just such a syntax. See attached.

> What I did is borrowed the generic options stuff that Peter Eisentraut
> introduced for FOREIGN DATA WRAPPER et. al, so you can write:

> EXPLAIN (option_name1 "option_value1", option_name2 "option_value2") query
> e.g. EXPLAIN (ANALYZE "on") query
Beeing the latest cause for the frustration leading to this patch I
obviously would like something like that - and I would gladly implement
some additional stats suggested by others(if implementable in a
reasonable timeframe) if this approach is agreed uppon.

> - I noticed that we currently acce pt as a top-level SQL command an
> arbitrarily parenthesized SELECT statement, like ((SELECT 3)). But
> you can't put parentheses around any other type of statement. Even
> more oddly, we also accept things like (SELECT 3) ORDER BY 1, which to
> me makes no sense at all.
I would guess that stems from supporting syntax like:
(SELECT 1)
UNION
(SELECT 2)
ORDER BY

and not wanting to introduce a special path for
(SELECT 1)
ORDER BY

For additional stats to be kept another discussion about appropriate,
extensible representation suitable for different output formats probably
would be needed - but thats a discussion for another day.

Andres