Prev: psql: ON_ERROR_STOP command-line flag for scripts
Next: [HACKERS] Functional dependencies and GROUP BY
From: "Greg Sabino Mullane" on 7 Jun 2010 09:59

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

Dean Rasheed wrote:
....
> So the current code in escape_yaml() is inadequate for producing valid
> YAML. I think it would have to also consider at least the following
> characters as special "-" ":" "[" "]" "{" "}" "," "\"" "'"
> "|" "*" "&". Technically, it would also need to trap empty strings,
> and strings with leading or trailing whitespace.
>
> Making escape_yaml() completely bulletproof with this approach would
> be quite difficult, and (IMO) not worth the effort
....

Doesn't seem like a lot of effort to me. You've already laid out most of
the exceptions above, although they require a few tweaks.
The rules should be:

Requires quoting only if the first character:
& * ! | > ' " % @ ` #

Same as above, but no quoting if the second character is "safe":
- ? :

Always requires quoting:
":<space>" "<space>#" aka ': ' ' #'

Always requires quoting:
, [ ] { }

Always require quoting:
(leading space) (trailing space) (empty string)

See:
http://yaml.org/spec/1.2/spec.html section 5.3 and 7.3.3


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

iEYEAREDAAYFAkwM+wAACgkQvJuQZxSWSsgWZACcCgb0rDvA6ZVhHId/q568gBGo
sjgAoLY7HbkI7sRpO45vi0jSRJ2Fiytk
=v7T/
-----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: "Greg Sabino Mullane" on 7 Jun 2010 10:37

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


Tom Lane wrote:
....
> Egad ... this is supposed to be an easily machine-generatable format?
>
> If it's really as broken as the above suggests, I think we should
> rip it out while we still can.

Heh ... not like you to shrink from a challenge. ;)

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.

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

iEYEAREDAAYFAkwNA+4ACgkQvJuQZxSWSshSswCg81kd3FdYnQup1eLWGesm+vm+
VO8AoL1Fwil/vXfRdRHx4A4zZUTDbZuT
=oPDv
-----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: Dean Rasheed on 7 Jun 2010 11:17
On 7 June 2010 15:56, Tom Lane <tgl(a)sss.pgh.pa.us> wrote:
> "Greg Sabino Mullane" <greg(a)turnstep.com> writes:
>> 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).
>
> I would go with that. �The quoting rules you proposed previously seem
> way too complicated --- meaning potentially buggy, and even if they're
> not buggy, the behavior would seem unpredictable to most users.
>

Well actually it's not just everything containing a special character,
it's also anything with leading or trailing whitespace, and empty
strings (not sure that can ever happen in practice).

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.

Regards,
Dean

--
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: Tom Lane on 7 Jun 2010 10:18
"Greg Sabino Mullane" <greg(a)turnstep.com> writes:
> The rules should be:

> Requires quoting only if the first character:
> & * ! | > ' " % @ ` #

> Same as above, but no quoting if the second character is "safe":
> - ? :

> Always requires quoting:
> ":<space>" "<space>#" aka ': ' ' #'

> Always requires quoting:
> , [ ] { }

> Always require quoting:
> (leading space) (trailing space) (empty string)

Egad ... this is supposed to be an easily machine-generatable format?

If it's really as broken as the above suggests, I think we should
rip it out while we still can.

regards, tom lane

--
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: Tom Lane on 7 Jun 2010 13:44
Greg Smith <greg(a)2ndquadrant.com> writes:
> The complaints about YAML taking up too much vertical space are
> understandable, but completely opposite of what I care about. I can
> e-mail a customer a YAML plan and it will survive to the other side and
> even in a reply back to me. Whereas any non-trivial text format one is
> guaranteed to utterly destroyed by line wrapping along the way.

> I think this thread could use a fresh example to remind anyone who
> hasn't played with the curent YAML format what it looks like.

So? This doesn't look amazingly unlike the current JSON output,
and to the extent that we have to add more quoting to it, it's
going to look even more like the JSON output.

Given the lack of any field separators other than newlines, I'm also
finding myself extremely doubtful about the claim that it survives
line-wrapping mutilations well. For instance this bit:

- Node Type: Seq Scan
Parent Relationship: Outer

doesn't appear to have anything but whitespace to distinguish it from

- Node Type: Seq Scan Parent
Relationship: Outer

regards, tom lane

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

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