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

From D'Arcy J.M. Cain
Subject Re: Proposal: new border setting in psql
Date
Msg-id 20090108105409.4b0dafab.darcy@druid.net
Whole thread Raw
In response to Re: Proposal: new border setting in psql  (Alvaro Herrera <alvherre@commandprompt.com>)
Responses Re: Proposal: new border setting in psql  (Bruce Momjian <bruce@momjian.us>)
Re: Proposal: new border setting in psql  (Greg Smith <gsmith@gregsmith.com>)
List pgsql-hackers
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 I ask what is this logical extension of the border feature useful
> for, keeping in mind that rst is not it?

Perhaps some people will like this format better.  I don't know.  I
want it for ReST.

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

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

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: WITH RECURSIVE ... CYCLE in vanilla SQL: issues with arrays of rows
Next
From: Stephen Frost
Date:
Subject: Re: Open item: kerberos warning message