On Thu, Feb 10, 2005 at 07:34:07PM -0500, Tom Lane wrote: > Martijn van Oosterhout <kleptog@xxxxxxxxx> writes: > > I've been wondering about that. A while ago the change was made from > > outputting a NOTICE with the EXPLAIN output to returning a resultset. > > If you could agree on what columns to return it might not be so hard > > for the EXPLAIN to return full tuples... > > The major stumbling block to that is that a table is inherently > unordered, so you'd have to devise a labeling scheme to allow the > node-tree structure to be represented properly. And without WITH or > CONNECT BY, it'd be a bit of a PITA for an application to decipher the > labeling scheme again ... To be honest, I'm not sure this a real problem. You could simply label the first columns a rownumber and a depth number. In extreme cases you might want a nodeid and an parent nodeid. But IMHO I don't think people are going to be doing analysis on the results from SQL. Much easier to just load the result into a perl (or some other PL) script and process it there. Maybe when WITH and CONNECT BY show up the capability should be there, but for now just returning the data should be fine. At the moment people are talking about parsing strings to get the output. That output has the same issues as what's being proposed here, we're just saving the parsing step. However, tuple based output would be quite unreadable for humans, how can one specify which output to return. EXPLAIN ANALYZE WITH TUPLES query? Have a nice day, -- Martijn van Oosterhout <kleptog@xxxxxxxxx> http://svana.org/kleptog/ > Patent. n. Genius is 5% inspiration and 95% perspiration. A patent is a > tool for doing 5% of the work and then sitting around waiting for someone > else to do the other 95% so you can sue them.
Attachment:
pgpYdNBSq7XAv.pgp
Description: PGP signature
