| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Dimitri Fontaine <dfontaine(at)hi-media(dot)com>, 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-25 15:02:53 |
| Message-ID: | 3331.1243263773@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:
> 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?
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Joshua Tolley | 2009-05-25 15:13:57 | Re: generic options for explain |
| Previous Message | Stephen Frost | 2009-05-25 14:57:36 | Re: No sanity checking performed on binary TIME parameters. |