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 <robertmh...@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.2080...@anarazel.de > [2] > http://archives.postgresql.org/message-id/603c8f070904151758w6af25641xac831b4cb71c4...@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 > > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
