Re: Invalid YAML output from EXPLAIN - Mailing list pgsql-bugs

From Dean Rasheed
Subject Re: Invalid YAML output from EXPLAIN
Date
Msg-id AANLkTim63I40z3UCIW1HtBsArlMcpSE4JcqvEGi37VCC@mail.gmail.com
Whole thread Raw
In response to Re: Invalid YAML output from EXPLAIN  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Invalid YAML output from EXPLAIN  (Dean Rasheed <dean.a.rasheed@gmail.com>)
Re: Invalid YAML output from EXPLAIN  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-bugs
On 9 June 2010 03:48, Robert Haas <robertmhaas@gmail.com> wrote:
> Er, I should also say, thanks for the report, and please test. =A0I am
> definitely not an expert on YAML.
>

I'm not an expert on YAML either, but I don't think this works (at
least it breaks against the online YAML parser here:
http://yaml-online-parser.appspot.com/). If the string starts with a
".", then it tries to treat it as a floating point number and baulks
if the rest of the string isn't a valid number.

Actually that gives me another argument for quoting *all* string
values: if a string value happens to be a valid number and we output
it unquoted, then parsers will treat is a number, forcing the user to
cast it to a string in their code. This is likely to lead to bugs in
user code, where things initially appear to work, then unexpectedly
start failing in pathalogical cases.

Personally, I'd also not try to escape keys at all. If in the future
we add a new key, then we'd be forced to choose between quoting it, or
more likely choosing a different key that doesn't require quoting,
which is what most people do in my (admittedly limited) experience.

In short, despite everything that's been said on this thread, I still
prefer my patch - but then I suppose I would say that :-)

Cheers,
Dean

pgsql-bugs by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Bad optimizer data for xml (WAS: xml data type implications of no =)
Next
From: Dave Page
Date:
Subject: Re: BUG #5475: Problem during Instalation