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
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 |