Re: Proposal: new border setting in psql - Mailing list pgsql-hackers

From Cédric Villemain
Subject Re: Proposal: new border setting in psql
Date
Msg-id 49662B31.1070000@dalibo.com
Whole thread Raw
In response to Re: Proposal: new border setting in psql  (Bruce Momjian <bruce@momjian.us>)
Responses Re: Proposal: new border setting in psql  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bruce Momjian a écrit :
> D'Arcy J.M. Cain wrote:
>> On Thu, 8 Jan 2009 12:30:52 -0300
>> Alvaro Herrera <alvherre@commandprompt.com> wrote:
>>>> It is a great feature for people actually using ReST.  However, the
>>>> feature is really just a logical extension to the existing border
>>>> attribute.
>>> Frankly I don't understand your position.  You seem to be saying that
>>> you want the logical extension to the border feature, because it's very
>>> easy to write, but you don't want to go to all the trouble of writing an
>>> actual rst output format -- I guess it's a lot more code.  You don't
>>> care that your new border format is not actually rst, because you have
>>> no need for rst.
>> In fact I wrote it because I do want it for ReST.  When I first
>> proposed it that was my sell.  I received pushback because it was for
>> too specific a purpose so I stepped back and showed that it was simply
>> a logical extension that happened to work as ReST input.  Now it seems
>> that unless it is 100% ReST and documented as such it will be rejected.
>>
>> I'm feeling the ground shift under me.
> 
> Can you find an email that shows this;  I don't remember a shift.

I do remember the same : ReSt was rejecting because it was too boring to maintin
or get a 100% compliant ouput (btw are we 100% compliant with any SQL ?)

So the option was to just add some options to handle the border in another fashion.

This kind of patch (improve border,style, .. of output) sound like a good idea
for me.

> 
>>> Some people suggests that this is so close to rst that I should just use
>>> it as if it were, and hand-edit the output for the rare cases where it
>>> doesn't comply.  I don't find this very compelling.
>> The cases are so rare that I can't remember what they were if any.
> 
> Well, Tom pointed out a few, the most obvious being backslashing markup
> characters:
> 
>     http://docutils.sourceforge.net/docs/user/rst/quickref.html#escaping
> 
> and there is a heck of a lot of markup:
> 
>     http://docutils.sourceforge.net/docs/user/rst/quickref.html#inline-markup
> 
> If you want another mode that doesn't do the backslashing, that is fine,
> but the ReST-required backslashes are necessary for it to be accepted.
> 
>>> Apparently the bottom line is that if it's not actual rst, it will get
>>> rejected.
>> OK, it's ReST.  If there is a corner case that breaks ReST I am willing
>> to treat it as a bug and fix it.
>>
>> Perhaps ReST should be the next level.  That way people who just want
>> the extra lines can get what they want and people who need 100% ReST
>> can use "border 4" instead.  That's if there is any difference of
>> course.  We could document "border 4" as ReST with no change to my code
>> patch until we find some case where "border 3" breaks ReST.
> 
> See above, there are lots of cases, and we aren't going to accept the
> patch with partial ReST support and wait for people to complain --- it
> is already clear the patch is not 100% ReST compliant.
> 


- --
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEARECAAYFAklmKysACgkQo/dppWjpEvz1PQCcDxu4cUeGDZGa+efCtbWe73pa
9dYAoKe2mqV1Mea4+UbtJJIMqNxGXvU9
=b+iU
-----END PGP SIGNATURE-----


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Proposal: new border setting in psql
Next
From: "Joshua D. Drake"
Date:
Subject: Re: Python 3.0 does not work with PL/Python