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

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

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

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

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

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

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

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

-BEGIN PGP SIGNED MESSAGE- Hash: RIPEMD160 > If the spec is in flux, that seems like More Than Sufficient reason > to reject the patch for the time being. It can be resubmitted when > it's no longer shooting at a moving target. Saying that it is in flux is a bit of a stretch. Even if i

Re: [HACKERS] YAML

Robert Haas writes: > +1. I'm a little concerned about the bit about the YAML specification > changing, too, but at least if we can ensure that we're compliant with > the spec that is current at the time the code goes in we have a leg to > stand on. If the spec is in flux, that seems like More T

Re: [HACKERS] YAML

On Tue, Dec 8, 2009 at 9:13 AM, Andrew Dunstan wrote: > Well, if we're going to commit this, as now appears likely, we should have > some language lawyers go over our code for both YAML and JSON with a fine > tooth comb to make sure what we are producing is strictly According To > Hoyle. +1. I'm

Re: [HACKERS] YAML

Tim Bunce wrote: I've no contribution to the main topic, but I'd like to point out that the "JSON is a subset of YAML" meme is not without controversy: http://search.cpan.org/~mlehmann/JSON-XS-2.26/XS.pm#JSON_and_YAML It may not be relevant in your use-case, but I thought it worth a mentio

Re: [HACKERS] YAML

On Mon, Dec 07, 2009 at 07:07:13PM -0500, Andrew Dunstan wrote: > > > Josh Berkus wrote: >>> Not everything is sanely convertible into some sort of plugin. A plugin >>> mechanism for this would be FAR more trouble that it is worth, IMNSHO. >>> >>> We are massively over-egging this pudding (as a cul

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

* 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

Tom Lane wrote: Andrew Dunstan writes: I was in fact prepared to commit this patch, despite some significant misgivings about its wisdom, mainly because it does have such a low impact. But then other people raised objections. I'm not sure how strong those objections are, though. T

Re: [HACKERS] YAML

Andrew Dunstan writes: > I was in fact prepared to commit this patch, despite some significant > misgivings about its wisdom, mainly because it does have such a low > impact. But then other people raised objections. I'm not sure how strong > those objections are, though. The "lite" version pos

Re: [HACKERS] YAML

Josh Berkus wrote: Not everything is sanely convertible into some sort of plugin. A plugin mechanism for this would be FAR more trouble that it is worth, IMNSHO. We are massively over-egging this pudding (as a culinary blogger you should appreciate this analogy). OK, then let's just acc

Re: [HACKERS] YAML

> Not everything is sanely convertible into some sort of plugin. A plugin > mechanism for this would be FAR more trouble that it is worth, IMNSHO. > > We are massively over-egging this pudding (as a culinary blogger you > should appreciate this analogy). OK, then let's just accept it. It's smal

Re: [HACKERS] YAML

Josh Berkus wrote: What it's sounding like is that we ought to have a plug-in (both for postmaster and for psql) which allows the calling of an external library to parse explain output. Then people could covert XML/JSON into whatever they wanted. It would be kinder to just reject the YAML pat

Re: [HACKERS] YAML

Josh Berkus wrote: All, What it's sounding like is that we ought to have a plug-in (both for postmaster and for psql) which allows the calling of an external library to parse explain output. Then people could covert XML/JSON into whatever they wanted. Not everything is sanely convertib

Re: [HACKERS] YAML

All, What it's sounding like is that we ought to have a plug-in (both for postmaster and for psql) which allows the calling of an external library to parse explain output. Then people could covert XML/JSON into whatever they wanted. --Josh Berkus -- Sent via pgsql-hackers mailing list (pgsql-

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

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

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

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

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

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

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

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

* 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

-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

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

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/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

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

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

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

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

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

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

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

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

> 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

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

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/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

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

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

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

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

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

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