Re: generic options for explain

Hello

why we develop a new syntax?

we should have a secondary function explain_query(query_string,
option) that returns setof some. Next function should be
explain_query_xml. I thing so for typical use EXPLAIN statement is
enough. And for machine procession some new function should be
perfect.

regards
Pavel Stehule

2009/5/24 Robert Haas <robertmhaas(at)gmail(dot)com>:
> 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
>
> As written, this patch doesn't introduce any actual new functionality,
> but I think it's pretty easy to see how we could build on the syntax
> to add things like different types of output formats, different types
> of instrumentation, etc.  A few other random notes:
>
> - This currently lacks documentation.  If we have any consensus that
> this is a reasonable approach, I'll add some.
> - I noticed that we currently accept 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.  But that's neither here nor there as far as
> this patch is concerned, except that it required some minor grammar
> hackery and a long comment explaining the hackery.
>
> Thoughts?
>
> ...Robert
>
> [1] http://archives.postgresql.org/message-id/4A16A8AF.2080508@anarazel.de
> [2] http://archives.postgresql.org/message-id/603c8f070904151758w6af25641xac831b4cb71c4184@mail.gmail.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>
>