Re: [BUGS] Invalid YAML output from EXPLAIN

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

> But YAML is not human-readable. There are human-readable subsets of
> it, but the general serializers do not produce them, and specific
> serializers are difficult to get right (as we've seen).

No, it *is* human readable. Indeed, that's one of the things that
differentiates it from JSON: readability is the main goal, whereas
JSON's goals are different. The readablity necessarily makes
the parsing rules more complex, but that's the implicit tradeoff.
(Did you miss the part where the other Greg is sending explain
plans via email?)

> What does your parser do with this (equivalent but shorter)
> YAML output?
>
> - Plan: !!map
> &0 Node Type: Sort
> &1 Startup Cost: 4449.30
> &2 Total Cost: 4496.80
> &3 Plan Rows: &5 19000
> &4 Plan Width: &6 268
> Sort Key: ["zip"]
> Plans: !!seq
> - *0: Seq Scan
> Parent Relationship: Outer
> Relation Name: &7 customers
> Alias: *7
> *1: 0.00
> *2: 726.00
> *3: *5
> *4: *6
> Filter: (customerid > 1000)

But we're not using alias nodes (nor would we ever want to), so I'm not
sure what the point of your contrived example is. That's shorter, but
certainly not easier to read by human /or/ machine.

> Looking at the spec, it's rather difficult to come up with a readable
> subset which can parsed easily and is general in the sense that it can
> express empty strings, strings with embedded newlines, and so on.
> YAML's rules for dealing with whitespace are fairly complex, but are
> probably needed to get a more compact notation than JSON.

I'll state that both embedded newlines and column names and values with
funny characters like '*' and '|' are rare events, and the great majority
of things you'll see in an explain plan are plain ol' ASCII, in which
YAML produces a very good representation. But you are right that we need
to make sure we are handling the whitespace correctly.

When I get some free time, I'll make a patch to implement as much of
the spec as we sanely can. As I said before, I don't think we need to
strive for putting everything we possibly can into "plain scalar"
objects, as we can cover 99% of the cases easy enough and fall back to
'when in doubt, quote' for the rest.

- --
Greg Sabino Mullane greg(at)turnstep(dot)com
End Point Corporation http://www.endpoint.com/
PGP Key: 0x14964AC8 201006080931
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkwOR2gACgkQvJuQZxSWSshkVwCgzqunUkawnBRGwOV8msQPudN8
UmkAoM1wz+wFCEz34CMJ7VH+S7T3mc43
=8OjG
-----END PGP SIGNATURE-----