Well I want an SQL query-able format. I also want a way to retrieve
the data for a query run from within an application without disturbing
the application i.e. while still returning the regular result set.
But I also like being able to conveniently run explain and get the
results formatted to fit on the screen in a single step. I don't see
anything wrong with Robert's direction to pass options to explain. It
doesn't solve every problem but it doesn't make any of the other
things we need harder either.
On a bike-shedding note I would rather have the rhs of the option be
optional and default to true for boolean options.
Actually if we make a set of explain_* guc options we could make the
options just locally set those options.
--
Greg
On 26 May 2009, at 13:15, Peter Eisentraut <pete...@gmx.net> wrote:
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
Robert Haas <robertmh...@gmail.com> writes:
This is all much more complicated than what I proposed, and I fail
to
see what it buys us. I'd say that you're just reinforcing the
point I
made upthread, which is that insisting that XML is the only way to
get
more detailed information will just create a cottage industry of
beating that XML output format into submission.
The impression I have is that (to misquote Churchill) XML is the
worst
option available, except for all the others. We need something
that can
represent a fairly complex data structure, easily supports addition
or
removal of particular fields in the structure (including fields not
foreseen in the original design), is not hard for programs to parse,
and is widely supported --- ie, "not hard" includes "you don't have
to
write your own parser, in most languages". How many realistic
alternatives are there?
I think we are going in the wrong direction. No one has said that
they want a
machine-readable EXPLAIN format. OK, there are historically about
three
people that want one, but they have already solved the problem of
parsing the
current format. And without having writtens such a parser myself I
think that
the current format is not inherently hard to parse.
What people really want is optional additional information in the
human-
readable format. Giving them a machine readable format does not
solve the
problem. Giving them a machine readable format with all-or-none of
the
optional information and saying "figure it out yourself" does not
solve
anything either. The same people who currently complain will
continue to
complain.
--
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
