Re: generic options for explain

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Dave Page <dpage(at)pgadmin(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: generic options for explain
Date: 2009-05-24 19:09:54
Message-ID: 3405.1243192194@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I wouldn't mind having a GUC to set the *default* explain behavior -
> but I'd still like to be able to override it for a particular command
> if I so choose. And that's not going to be possible with your syntax:
> if explain_format is set to 'xml, verbose' and I want plain text
> output for one command, how do I get it? Presumably I have to change
> explain_format, run my EXPLAIN, and then change it back again. Blech!

You know about SET LOCAL, no? I don't think this argument is very
convincing.

On the other side of the coin, I'm strongly against inventing more than
one new output format for EXPLAIN, and so any argument that depends on
examples such as "xml vs json" is falling on deaf ears here. I think
that we only need an XML option, and so EXPLAIN ANALYZE XML ... doesn't
seem untenable. What other options than those do you really need?
Not ones to add or remove output fields; we'd expect the client to
ignore fields it doesn't care about.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Ben Ali Rachid 2009-05-24 20:03:27 Re: Oracle to Postgres : create type as object in Postgres
Previous Message Robert Haas 2009-05-24 19:01:54 Re: pull raw text of a message by message-id