Prev: psql: ON_ERROR_STOP command-line flag for scripts
Next: [HACKERS] Functional dependencies and GROUP BY
From: Robert Haas on 7 Jun 2010 10:49
On Mon, Jun 7, 2010 at 10:37 AM, Greg Sabino Mullane <greg(a)turnstep.com> wrote:
> Tom Lane wrote:
> I don't think the above would be particularly hard to implement myself,
> but if it becomes a really big deal, we can certainly punt by simply
> quoting anything containing an indicator (the special characters above).
> It will still be 100% valid YAML, just with some excess quoting for the
> very rare case when a value contains one of the special characters.

Since you're the main advocate of this feature, I think you should
implement it rather than leaving it to Tom or I.

The reason why I was initially skeptical of adding a YAML output
format is that JSON is a subset of YAML. Therefore, the JSON output
format ought to be perfectly sufficient for anyone using a YAML
parser. If it's not, that's because their YAML processor is broken,
and they should get a new one, or because the YAML spec is defective.
The YAML format got voted in by consensus because people thought that
it would also make a nice alternative to the text format for human
readable output. I don't believe that (it uses way too much vertical
space) but even if you accept the argument, the more we make the YAML
format look like the JSON format, the less water that argument holds.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Josh Berkus on 7 Jun 2010 14:26

> It's because of the potential for bugs in this area, that I'd propose
> just quoting everything (except numeric values) as in my original
> patch.

I don't see a problem with this.

I supported YAML output because I find it easier to read and copy&paste
than the other outputs. This is still the case even with quoting. And
it's not exactly a hugely intrusive patch.

--
-- Josh Berkus
PostgreSQL Experts Inc.
http://www.pgexperts.com

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Greg Sabino Mullane" on 8 Jun 2010 09:37

-----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(a)turnstep.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-----



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Robert Haas on 8 Jun 2010 21:51
On Tue, Jun 8, 2010 at 9:37 AM, Greg Sabino Mullane <greg(a)turnstep.com> wrote:
> When I get some free time, I'll make a patch to implement as much of
> the spec as we sanely can.

Saying that you'll fix it but not on any particular timetable is
basically equivalent to saying that you're not willing to fix it at
all. We are trying to get a release out the door. I'm not trying to
be rude, but it's frustrating to me when people object to having their
code ripped out but also won't commit to getting it fixed in a timely
fashion.

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

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Greg Sabino Mullane" on 9 Jun 2010 11:57

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


Robert Haas wrote:
>> When I get some free time, I'll make a patch to implement as
>> much of the spec as we sanely can.

> Saying that you'll fix it but not on any particular timetable is
> basically equivalent to saying that you're not willing to fix it at
> all.

It's not equivalent at all. If I wasn't willing to fix it all,
I'd say so.

> We are trying to get a release out the door. I'm not trying to
> be rude, but it's frustrating to me when people object to having their
> code ripped out but also won't commit to getting it fixed in a timely
> fashion.

You might not be trying, but you are coming across as quite rude. The
bug was only reported Monday morning, and you are yelling at me
on a Tuesday night for not being willing to drop everything I'm doing
and fix it right now? Yes, we're heading towards 9.0 and yes, I'd
sure hate to see YAML ripped out (especially now that it's been
listed near and far as one of our new features), but I've got bills
to pay and writing a patch is a volunteer effort for me.

Since you seem so keen on telling other people what they should be
doing, here's some of your own medicine: why not focus on something
other than YAML, which myself and many other people can write, and
work more on the 9.0 open issues that your energy and expertise
would be more suited for?

- --
Greg Sabino Mullane greg(a)turnstep.com
PGP Key: 0x14964AC8 201006091156
http://biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8
-----BEGIN PGP SIGNATURE-----

iEYEAREDAAYFAkwPuawACgkQvJuQZxSWSshqSwCgyUoNhi8r/ug/joERXJfJF4mu
3h4AoOtLUHWcN3udePN1Ne2jc+gBa/uS
=OtxW
-----END PGP SIGNATURE-----



--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: psql: ON_ERROR_STOP command-line flag for scripts
Next: [HACKERS] Functional dependencies and GROUP BY