2009/5/25 Tom Lane <t...@sss.pgh.pa.us>: > Greg Smith <gsm...@gregsmith.com> writes: >> On Sun, 24 May 2009, Pavel Stehule wrote: >>> we should have a secondary function explain_query(query_string, >>> option) that returns setof some. > >> +1. The incremental approach here should first be adding functions that >> actually do the work required. Then, if there's a set of those that look >> to be extremely useful, maybe at that point it's worth talking about how >> to integrate them into the parser. Starting with the parser changes >> rather than the parts that actually do the work is backwards. If you do >> it the other way around, at all times you have a patch that actually >> provides immediate useful value were it to be committed. > >> Something that returns a setof can also be easily used to implement the >> "dump EXPLAIN to a table" feature Josh Tolley brought up (which is another >> common request in this area). > > A serious problem with EXPLAIN via a function returning set, or with > putting the result into a table, is that set results are logically > unordered, just as table contents are. So from a strict point of view > this only makes sense when the output format is designed to not depend > on row ordering to convey information. We could certainly invent such > a format, but I think it's a mistake to go in this direction for > EXPLAIN output that is similar to the current output.
I don't expect so functional EXPLAIN will be used by users directly. It' data source for some "GUI". And currently with CTE, there are not problem transform query to similar output like current EXPLAIN. I am able to understand some new parameters for explain statement (when result will be directly read by user), but some output options (or formating options) I would to see in some other functions. regards Pavel Stehule > > regards, tom lane > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
