On Wed, Jun 9, 2010 at 7:23 AM, Dean Rasheed <[email protected]> wrote: > On 9 June 2010 12:07, Robert Haas <[email protected]> wrote: >> On Wed, Jun 9, 2010 at 2:58 AM, Dean Rasheed <[email protected]> >> wrote: >>> On 9 June 2010 03:48, Robert Haas <[email protected]> wrote: >>>> Er, I should also say, thanks for the report, and please test. I 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. >> >> Really? I enter: >> >> - foo >> - bar >> - .baz >> >> And it produces this JSON: >> >> [ >> "foo", >> "bar", >> ".baz" >> ] >> >> That looks OK to me. >> > > Ah, OK I didn't test those cases properly before composing my email. > It's actually only a "." on its own that it can't parse.
Well, at first blush, that looks like it might be a bug in the parser. I don't see anything in the spec to indicate that that case should be treated specially. > My comment about numbers still applies though. The following are > different values: > > - just: write some > - yaml: > - 123 > - "123" Well, you can't have abc mean the same thing as "abc" but then complain that 123 isn't equivalent to "123"... This format is really a pain to work with. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
