Re: Invalid YAML output from EXPLAIN

On Wed, Jun 9, 2010 at 12:58 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Jun 9, 2010 at 12:57 PM, Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> wrote:
>> On 9 June 2010 17:52, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>> On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>>>> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>>>>> Why not?  Surely we can restrict EXPLAIN's set of key names to be safe.
>>>>
>>>>> It seems to me that it would be easy for a future patch to break this
>>>>> by accident.
>>>>
>>>> Really?  What likely key names would be in need of quoting?  I can't
>>>> imagine accepting a field name that contains punctuation or leading
>>>> or trailing whitespace, for example.
>>>
>>> It seemed to me, in particular, that someone might use a # symbol,
>>> like "# of Iterations".
>>>
>>
>> Then the resulting XML tagname would be invalid too
>> I think they would soon realise/be told that it was a bad idea.
>
> Hmm, you're right.  Maybe we should go with your approach, then.

After thinking about this further, I think I'd still like to take one
more crack at fixing this without quoting absolutely everything. I
argued against this feature, but we decided to take it, and it seems
that one of the major arguments that is being put forward is that it
will be more readable than JSON, because it will have less
punctuation. While the idea of optimizing a machine-readable format
for human-readability doesn't typically carry much water around here,
it's really the only use case for having this particular feature at
all, so, if we're not going to rip it out, ISTM we ought to respect
what it's there for. I would be more than willing to agree that if
one more attempt isn't sufficient to fix the problem then we'll either
quote everything, or rip the whole thing out.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company