Tom Lane wrote:
> Bruce Momjian writes:
> > So, is there still value to a YAML format vs. JSON? They look similar
> > to me in this simple case:
>
> Well, removing the various braces and brackets reduces the line count
> significantly. Not convinced it's really worth much though.
Ah, I see tha
Bruce Momjian writes:
> So, is there still value to a YAML format vs. JSON? They look similar
> to me in this simple case:
Well, removing the various braces and brackets reduces the line count
significantly. Not convinced it's really worth much though.
regards, tom lane
Robert Haas wrote:
> On Wed, Jun 9, 2010 at 4:48 PM, Robert Haas wrote:
> > On Wed, Jun 9, 2010 at 4:47 PM, Dean Rasheed
> > wrote:
> >> On 9 June 2010 20:56, Robert Haas wrote:
> >>> On Wed, Jun 9, 2010 at 3:50 PM, Tom Lane wrote:
> Dean Rasheed writes:
> > Hmm. Well it's quite subj
On Wed, Jun 9, 2010 at 4:48 PM, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 4:47 PM, Dean Rasheed wrote:
>> On 9 June 2010 20:56, Robert Haas wrote:
>>> On Wed, Jun 9, 2010 at 3:50 PM, Tom Lane wrote:
Dean Rasheed writes:
> Hmm. Well it's quite subjective, but IMO it's already more re
On 9 June 2010 20:56, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 3:50 PM, Tom Lane wrote:
>> Dean Rasheed writes:
>>> Hmm. Well it's quite subjective, but IMO it's already more readable
>>> than JSON regardless of whether or not values are quoted, simply
>>> because it doesn't have [ ] and { }
On Wed, Jun 9, 2010 at 4:47 PM, Dean Rasheed wrote:
> On 9 June 2010 20:56, Robert Haas wrote:
>> On Wed, Jun 9, 2010 at 3:50 PM, Tom Lane wrote:
>>> Dean Rasheed writes:
Hmm. Well it's quite subjective, but IMO it's already more readable
than JSON regardless of whether or not values
Dean Rasheed writes:
> Hmm. Well it's quite subjective, but IMO it's already more readable
> than JSON regardless of whether or not values are quoted, simply
> because it doesn't have [ ] and { } for lists and maps, which for JSON
> adds significantly to the number of lines in longer plans.
Yeah.
On 9 June 2010 19:50, Robert Haas wrote:
> After thinking about this further, I think I'd still like to take one
> more crack at fixing this without quoting absolutely everything. I
> argued against this feature, but we decided to take it, and it seems
> that one of the major arguments that is be
On Wed, Jun 9, 2010 at 3:50 PM, Tom Lane wrote:
> Dean Rasheed writes:
>> Hmm. Well it's quite subjective, but IMO it's already more readable
>> than JSON regardless of whether or not values are quoted, simply
>> because it doesn't have [ ] and { } for lists and maps, which for JSON
>> adds signi
On Wed, Jun 9, 2010 at 12:58 PM, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 12:57 PM, Dean Rasheed
> wrote:
>> On 9 June 2010 17:52, Robert Haas wrote:
>>> On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane wrote:
Robert Haas writes:
> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
>>
On Wed, Jun 9, 2010 at 12:58 PM, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 12:57 PM, Dean Rasheed
> wrote:
>> On 9 June 2010 17:52, Robert Haas wrote:
>>> On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane wrote:
Robert Haas writes:
> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
>>
On 9 June 2010 14:14, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 8:46 AM, Dean Rasheed wrote:
>> On 9 June 2010 03:48, Robert Haas 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
On Wed, Jun 9, 2010 at 12:57 PM, Dean Rasheed wrote:
> On 9 June 2010 17:52, Robert Haas wrote:
>> On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane wrote:
>>> Robert Haas writes:
On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
> Why not? Surely we can restrict EXPLAIN's set of key names to
On 9 June 2010 17:52, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
Why not? Surely we can restrict EXPLAIN's set of key names to be safe.
>>
>>> It seems to me that it would be easy for a
On Wed, Jun 9, 2010 at 12:25 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
>>> Why not? Surely we can restrict EXPLAIN's set of key names to be safe.
>
>> It seems to me that it would be easy for a future patch to break this
>> by accident.
>
> Re
On 9 June 2010 17:25, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
>>> Why not? Surely we can restrict EXPLAIN's set of key names to be safe.
>
>> It seems to me that it would be easy for a future patch to break this
>> by accident.
>
> Really? What
Robert Haas writes:
> On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
>> Why not? Surely we can restrict EXPLAIN's set of key names to be safe.
> It seems to me that it would be easy for a future patch to break this
> by accident.
Really? What likely key names would be in need of quoting? I
On Wed, Jun 9, 2010 at 11:14 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 11:03 AM, Tom Lane wrote:
>>> I still agree with Dean's original proposal: always quote the values of
>>> strings.
>
>> I'd still rather rip the format out entirely than do that.
>
> I'd be on board
Dean Rasheed wrote:
> So that just leaves this sort of thing:
>
> explain (format yaml) select * from foo as "123";
What about other quoted identifiers? If I recall correctly, a
quoted identifier can contain *any* characters (although a quote
must be represented as two adjacent quotes).
te
On 9 June 2010 16:05, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 11:03 AM, Tom Lane wrote:
>> Robert Haas writes:
>>> On Wed, Jun 9, 2010 at 9:35 AM, Dean Rasheed
>>> wrote:
> Does anyone care that Alias will sometimes be a string, and sometimes a
> number?
>>
>>> After further revie
Robert Haas writes:
> On Wed, Jun 9, 2010 at 11:03 AM, Tom Lane wrote:
>> I still agree with Dean's original proposal: always quote the values of
>> strings.
> I'd still rather rip the format out entirely than do that.
I'd be on board with that too ;-)
> Dean's
> proposal was based on the idea
On Wed, Jun 9, 2010 at 11:03 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Wed, Jun 9, 2010 at 9:35 AM, Dean Rasheed
>> wrote:
Does anyone care that Alias will sometimes be a string, and sometimes a
number?
>
>> After further review, it appears to me that this change is pretty much
Robert Haas writes:
> On Wed, Jun 9, 2010 at 9:35 AM, Dean Rasheed wrote:
>>> Does anyone care that Alias will sometimes be a string, and sometimes a
>>> number?
> After further review, it appears to me that this change is pretty much
> required, because otherwise a string like 0xa won't be quo
On Wed, Jun 9, 2010 at 9:35 AM, Dean Rasheed wrote:
>>> Does anyone care that Alias will sometimes be a string, and sometimes a
>>> number?
>> 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,
On Wed, Jun 9, 2010 at 8:46 AM, Dean Rasheed wrote:
> On 9 June 2010 03:48, Robert Haas 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
On 9 June 2010 03:48, Robert Haas 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
On 9 June 2010 12:32, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 7:23 AM, Dean Rasheed wrote:
>> On 9 June 2010 12:07, Robert Haas wrote:
>>> On Wed, Jun 9, 2010 at 2:58 AM, Dean Rasheed
>>> wrote:
On 9 June 2010 03:48, Robert Haas wrote:
> Er, I should also say, thanks for the repo
On Wed, Jun 9, 2010 at 7:23 AM, Dean Rasheed wrote:
> On 9 June 2010 12:07, Robert Haas wrote:
>> On Wed, Jun 9, 2010 at 2:58 AM, Dean Rasheed
>> wrote:
>>> On 9 June 2010 03:48, Robert Haas wrote:
Er, I should also say, thanks for the report, and please test. I am
definitely not an
On 9 June 2010 12:07, Robert Haas wrote:
> On Wed, Jun 9, 2010 at 2:58 AM, Dean Rasheed wrote:
>> On 9 June 2010 03:48, Robert Haas 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, bu
On Wed, Jun 9, 2010 at 2:58 AM, Dean Rasheed wrote:
> On 9 June 2010 03:48, Robert Haas 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 a
On 9 June 2010 07:58, Dean Rasheed wrote:
> I prefer my patch - but then I suppose I would say that :-)
>
Seriously though, I can think of a number of good arguments in favour
of the "quote all string values unconditionally" approach:
- It's the simplest, least obtrusive fix to our code.
- It's
On 9 June 2010 03:48, Robert Haas 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.a
On Tue, Jun 8, 2010 at 10:47 PM, Robert Haas wrote:
> On Mon, Jun 7, 2010 at 4:14 AM, Dean Rasheed wrote:
>> Testing 9.0 beta, I found that EXPLAINing certain queries in YAML
>> format will produce invalid YAML, for example:
>>
>> explain (format yaml) select * from foo where str_val = 'a: b';
>>
On Mon, Jun 7, 2010 at 4:14 AM, Dean Rasheed wrote:
> Testing 9.0 beta, I found that EXPLAINing certain queries in YAML
> format will produce invalid YAML, for example:
>
> explain (format yaml) select * from foo where str_val = 'a: b';
>
> The problem in this case is that a colon followed by whit
* Greg Smith:
> Florian Weimer wrote:
>> It has been claimed before that YAML is a superset of JSON, so why
>> can't the YAML folks use the existing JSON output instead?
>>
>
> Because JSON just crosses the line where it feels like there's so much
> markup that people expect a tool is necessary
Tom Lane wrote:
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.
I don't know about that; here's the JSON one:
EXPLAIN (FORMAT JSON) SELECT * FROM customers WHERE customer
Greg Smith 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 forma
Florian Weimer wrote:
It has been claimed before that YAML is a superset of JSON, so why
can't the YAML folks use the existing JSON output instead?
Because JSON just crosses the line where it feels like there's so much
markup that people expect a tool is necessary to read it, which has
alw
* Tom Lane:
> Egad ... this is supposed to be an easily machine-generatable format?
Perhaps you could surround all strings with "" in the generator, and
escape all potentially special characters (which seems to include some
whitespace even in quoted strings, unfortunately)?
It has been claimed b
On 7 June 2010 15:56, Tom Lane wrote:
> "Greg Sabino Mullane" 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).
>
>
"Greg Sabino Mullane" 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
Robert Haas wrote:
On Mon, Jun 7, 2010 at 10:37 AM, Greg Sabino Mullane 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
On Mon, Jun 7, 2010 at 10:37 AM, Greg Sabino Mullane 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).
-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.
"Greg Sabino Mullane" 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:
> ":" "#" aka ': ' ' #'
> Always requires quoting
-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 "-" ":" "[" "]" "{" "}" "," "\"" "'"
> "|" "*"
Testing 9.0 beta, I found that EXPLAINing certain queries in YAML
format will produce invalid YAML, for example:
explain (format yaml) select * from foo where str_val = 'a: b';
The problem in this case is that a colon followed by whitespace is not
allowed in an unquoted plain YAML string because
47 matches
Mail list logo
