Re: generic options for explain - Mailing list pgsql-hackers
From | Pavel Stehule |
---|---|
Subject | Re: generic options for explain |
Date | |
Msg-id | 162867790905232131o3f94b76bh421f9348b8fc5f84@mail.gmail.com Whole thread Raw |
In response to | generic options for explain (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: generic options for explain
(Dave Page <dpage@pgadmin.org>)
Re: generic options for explain (Greg Smith <gsmith@gregsmith.com>) |
List | pgsql-hackers |
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@gmail.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@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > >
pgsql-hackers by date: