Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-10 Thread Takahiro Itagaki
Robert Haas wrote: > On Thu, Dec 10, 2009 at 8:39 PM, Andrew Dunstan wrote: > > OK, I've committed the YAML stuff, so who is working on the auto-explain > > bug? Robert? > > I'm going to propose fixing this in what seems to me to be the > simplest possible way, per the attached. Anyone want t

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-10 Thread Robert Haas
On Thu, Dec 10, 2009 at 8:39 PM, Andrew Dunstan wrote: > OK, I've committed the YAML stuff, so who is working on the auto-explain > bug? Robert? I'd like that fixed before I add in the query text to > auto-explain output. I'm going to propose fixing this in what seems to me to be the simplest pos

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-10 Thread Andrew Dunstan
Tom Lane wrote: Greg Smith writes: To be clear about which version we're talking about: http://archives.postgresql.org/message-id/20091130123456.4a03.52131...@oss.ntt.co.jp is the candidate for commit that includes the cleanup you've already done. I suppose this is subject to the

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-08 Thread Tom Lane
Greg Smith writes: > To be clear about which version we're talking about: > http://archives.postgresql.org/message-id/20091130123456.4a03.52131...@oss.ntt.co.jp > > is the candidate for commit that includes the cleanup you've already done. I suppose this is subject to the same auto_explain pr

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-08 Thread Andrew Dunstan
Greg Smith wrote: Takahiro Itagaki wrote: Can I ask the final decision whether the YAML formatter should be applied or rejected? As far as I read the discussion, we can apply it because serveral users want it and we don't have a plan to support extensible formatters in the core. The path I

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-08 Thread Greg Smith
Takahiro Itagaki wrote: Can I ask the final decision whether the YAML formatter should be applied or rejected? As far as I read the discussion, we can apply it because serveral users want it and we don't have a plan to support extensible formatters in the core. The path I thought made sense a

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-08 Thread Takahiro Itagaki
Can I ask the final decision whether the YAML formatter should be applied or rejected? As far as I read the discussion, we can apply it because serveral users want it and we don't have a plan to support extensible formatters in the core. Greg Smith wrote: > -The patch is small to apply > -Having

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Florian Weimer
* Alvaro Herrera: > Florian Weimer escribió: >> * Dimitri Fontaine: >> >> > Well we have JSON and agreed it was a good idea to have it. Now JSON is >> > a subset of YAML and some would prefer another YAML style (me included). >> >> YAML is rather difficult to parse, and most parsers assume a tru

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread David E. Wheeler
On Dec 7, 2009, at 9:52 AM, Alvaro Herrera wrote: >> Tallying up the votes on this patch, we have Tom Lane, Andrew Dunstan, >> Josh Drake, and myself arguing against including this in core, and >> Josh Berkus and Itagaki Takahiro arguing for it. Ron Mayer seemed >> somewhat in favor of it in his

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Joshua D. Drake
On Mon, 2009-12-07 at 14:52 -0300, Alvaro Herrera wrote: > Robert Haas escribió: > > > Tallying up the votes on this patch, we have Tom Lane, Andrew Dunstan, > > Josh Drake, and myself arguing against including this in core, and > > Josh Berkus and Itagaki Takahiro arguing for it. Ron Mayer seeme

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Alvaro Herrera
Robert Haas escribió: > Tallying up the votes on this patch, we have Tom Lane, Andrew Dunstan, > Josh Drake, and myself arguing against including this in core, and > Josh Berkus and Itagaki Takahiro arguing for it. Ron Mayer seemed > somewhat in favor of it in his message on-list but sent a messa

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Alvaro Herrera
Florian Weimer escribió: > * Dimitri Fontaine: > > > Well we have JSON and agreed it was a good idea to have it. Now JSON is > > a subset of YAML and some would prefer another YAML style (me included). > > YAML is rather difficult to parse, and most parsers assume a trusted > document source beca

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Ron Mayer
Greg Smith wrote: > That's a step backwards. By providing JSON format, we've also satisfied > people who want YAML. Ripping out JSON would mean we *only* support > YAML. There are far many more JSON parsers than YAML parsers, which is > why I thought the current code committed was good enough.

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Greg Smith
Dimitri Fontaine wrote: If the problem is supporting 2 formats in core rather than 3, what about replacing the current JSON support with the YAML one? That's a step backwards. By providing JSON format, we've also satisfied people who want YAML. Ripping out JSON would mean we *only* support

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Tom Lane
Itagaki Takahiro writes: > Tom Lane wrote: >> It was written and submitted by one person who did not bother to ask >> first whether anyone else thought it was worthwhile. So its presence >> on the CF list should not be taken as evidence that there's consensus >> for it. > Should we have "Needs

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Florian Weimer
* Dimitri Fontaine: > Well we have JSON and agreed it was a good idea to have it. Now JSON is > a subset of YAML and some would prefer another YAML style (me included). YAML is rather difficult to parse, and most parsers assume a trusted document source because they support arbitrary class instan

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Greg Sabino Mullane
-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > Tallying up the votes on this patch First, I would hope that you don't overlook the author of the patch (me) as an "aye" vote. :) Additionally, if you are going t

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Peter Eisentraut
On mån, 2009-12-07 at 17:14 +0900, Hitoshi Harada wrote: > 2009/12/7 Itagaki Takahiro : > > > > Tom Lane wrote: > > > >> It was written and submitted by one person who did not bother to ask > >> first whether anyone else thought it was worthwhile. So its presence > >> on the CF list should not be

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Dimitri Fontaine
Hi, Greg Smith writes: > Robert Haas wrote: >> The main point here for me is that the JSON format is already >> parseable by YAML parsers, and can probably be turned into YAML using >> a very short Perl script - possibly even using a sed script. I think >> that it's overkill to support two forma

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-07 Thread Hitoshi Harada
2009/12/7 Itagaki Takahiro : > > Tom Lane wrote: > >> It was written and submitted by one person who did not bother to ask >> first whether anyone else thought it was worthwhile.  So its presence >> on the CF list should not be taken as evidence that there's consensus >> for it. > > Should we have

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-06 Thread Itagaki Takahiro
Tom Lane wrote: > It was written and submitted by one person who did not bother to ask > first whether anyone else thought it was worthwhile. So its presence > on the CF list should not be taken as evidence that there's consensus > for it. Should we have "Needs Discussion" phase before "Needs

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-06 Thread Tom Lane
Greg Smith writes: > Given the above, I don't understand why writing this patch was deemed > worthwhile in the first place, It was written and submitted by one person who did not bother to ask first whether anyone else thought it was worthwhile. So its presence on the CF list should not be take

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-06 Thread Greg Smith
Robert Haas wrote: The main point here for me is that the JSON format is already parseable by YAML parsers, and can probably be turned into YAML using a very short Perl script - possibly even using a sed script. I think that it's overkill to support two formats that are that similar. It's not

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-06 Thread Robert Haas
On Sun, Dec 6, 2009 at 8:34 PM, Itagaki Takahiro wrote: > > Josh Berkus wrote: > >> Having compared the JSON and YAML output formats, I think having YAML as >> a 2nd human-readable format might be valuable, even though it adds >> nothing to machine-processing. > > Sure. YAML is human readable and

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-06 Thread Itagaki Takahiro
Josh Berkus wrote: > Having compared the JSON and YAML output formats, I think having YAML as > a 2nd human-readable format might be valuable, even though it adds > nothing to machine-processing. Sure. YAML is human readable and can print more information that is too verbose in one-line text fo

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-05 Thread Euler Taveira de Oliveira
Ron Mayer escreveu: > While there's no great way to make this a contrib module today, > would it make sense to add such hooks for an eventual module system? > I don't think so. It's easier to code a converter tool. -- Euler Taveira de Oliveira http://www.timbira.com/ -- Sent via pgsql-hac

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-05 Thread Ron Mayer
Josh Berkus wrote: >> ... YAML for easier readability ... > > "almost as good" ... I agree with Kevin that it's more readable. > > Again, if there were a sensible way to do YAML as a contrib module, I'd > go for that, but there isn't. Perhaps that's be a direction this could take? What would i

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-04 Thread Robert Haas
On Fri, Dec 4, 2009 at 7:42 PM, Josh Berkus wrote: >> On top of that, if you did want YAML for easier readability, what >> aspect of the output is more readable in YAML than it is in text >> format?  The only answer I can think of is that you like having each >> data element on a separate line, so

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-04 Thread Josh Berkus
> On top of that, if you did want YAML for easier readability, what > aspect of the output is more readable in YAML than it is in text > format? The only answer I can think of is that you like having each > data element on a separate line, so that the plan is much longer but > somewhat narrower.

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-04 Thread Robert Haas
On Wed, Dec 2, 2009 at 4:24 PM, Tom Lane wrote: > Ron Mayer writes: >> Tom Lane wrote: >>> Hmm.  So the argument for it is "let's make a machine-readable format >>> more human-readable"?  I'm not getting the point.  People should look >>> at the regular text output. > >> IMHO YAML beats the regul

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-02 Thread Tom Lane
Ron Mayer writes: > Tom Lane wrote: >> Hmm. So the argument for it is "let's make a machine-readable format >> more human-readable"? I'm not getting the point. People should look >> at the regular text output. > IMHO YAML beats the regular text format for human-readability - > at least for peo

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-02 Thread Brendan Jurd
2009/12/3 Ron Mayer : > Tom Lane wrote: >> Hmm.  So the argument for it is "let's make a machine-readable format >> more human-readable"?  I'm not getting the point.  People should look >> at the regular text output. > > IMHO YAML beats the regular text format for human-readability - > at least for

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-02 Thread Joshua D. Drake
On Wed, 2009-12-02 at 10:45 -0800, Josh Berkus wrote: > All, > > If some people want it, and there's no significant maintenance burden > associated with YAML output, then why not? > > Mind you, if it was practical, I'd suggest that YAML ... and all > additional Explain formats ... should be a con

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-02 Thread Josh Berkus
All, If some people want it, and there's no significant maintenance burden associated with YAML output, then why not? Mind you, if it was practical, I'd suggest that YAML ... and all additional Explain formats ... should be a contrib module. Anything other than XML and JSON will be fairly margin

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-02 Thread Ron Mayer
Tom Lane wrote: > Andrew Dunstan writes: >> YAML... > > Hmm. So the argument for it is "let's make a machine-readable format > more human-readable"? I'm not getting the point. People should look > at the regular text output. IMHO YAML beats the regular text format for human-readability - at l

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-02 Thread Tom Lane
Andrew Dunstan writes: > YAML and JSON are pretty much interchangeable for our purposes. > According to Wikipedia, "Both functionally and syntactically, JSON is > effectively a subset of YAML." See > So the YAML parsers should be > able to handle the JS

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-02 Thread Andrew Dunstan
Josh Berkus wrote: On 11/30/09 8:17 PM, Andrew Dunstan wrote: Do we have consensus yet that we want YAML? It seemed, well, yet another format without all that much advantage over what's there. Well, what's the code count? What dependencies, if any, does it add? The patch its

Re: [HACKERS] YAML Was: CommitFest status/management

2009-12-01 Thread Josh Berkus
On 11/30/09 8:17 PM, Andrew Dunstan wrote: > Do we have consensus yet that we want YAML? It seemed, well, > yet another format without all that much advantage over what's > there. Well, what's the code count? What dependencies, if any, does it add? --Josh -- Sent via pgsql-hackers mailing lis