On Wed, Jun 9, 2010 at 8:46 AM, Dean Rasheed <dean.a.rash...@gmail.com> wrote: > On 9 June 2010 03:48, Robert Haas <robertmh...@gmail.com> wrote: >> please test. > > Well your patch definitely fixes my original bug, and AFAICT always > produces valid YAML output now. I've only found one case where a > particular parser has difficulty parsing the output, and you'd have to > write a pretty perverse query to hit that case.
Excellent. > So that just leaves this sort of thing: > > explain (format yaml) select * from foo as "123"; > QUERY PLAN > ------------------------- > - Plan: + > Node Type: Seq Scan+ > Relation Name: foo + > Alias: 123 + > Startup Cost: 0.00 + > Total Cost: 23.10 + > Plan Rows: 1310 + > Plan Width: 32 > (1 row) > > Does anyone care that Alias will sometimes be a string, and sometimes a > number? > > ITSM that, since postgresql knows that it's a string, it ought to > output something that parsers can unambiguously treat as a string too. > > But this is also a pretty obscure case that probably only someone > deliberately trying to be awkward would do (which is me, with my > tester hat on :-)). I guess we could do this by (a) conditionalizing the YAML case in ExplainProperty() in the same way that the JSON case is currently conditionalized, and (b) changing the first if statement in escape_yaml() to set needs_quoting = true unless the first character is alphabetic or an underscore. By the way, can I ask why you're not just using the JSON format for this? I mean, I'm glad you are, because it exposed a bug that we got fixed before release, but it seems a little masochistic...! -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
