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 20080829143201.7594bb78.darcy@druid.net
Whole thread Raw
In response to Re: Proposal: new border setting in psql  (Gregory Stark <stark@enterprisedb.com>)
List pgsql-hackers
On Fri, 29 Aug 2008 18:07:36 +0100
Gregory Stark <stark@enterprisedb.com> wrote:
> I'm starting to think D'Arcy's on the right track here. 

Is that the train coming?  :-)

> Keep in mind the use case here is as Alvaro says, just a user convenience
> thing. It's not meant for file dumps and loads. If we're going to display an
> ascii table we may as well use the same formatting as other tools so it can be
> copy/pasted in.

Well, Tom makes a good point about trying to make it fit one specific
markup language perfectly.  The important thing here is that it stand
on its own as a nice display.

> Given that it's just a user convenience thing then I'm not sure the escaping
> is necessarily a big deal. If the user happens to have any backslashes in
> their data they can always stick a replace() call in their SQL. Perhaps we
> should prove a rest_escape() function for that purpose.

I think that a setting is just a lot cleaner.  Remember, the use case
here is that someone wants to do an ad-hoc query and drop it into some
other tool.  A simple "SELECT * FROM table" should work.

> I wonder if it's worth keeping two variants at all really. Why not just make
> psql's native table formatting exactly ReST? Is there any part of it that we
> don't like as much as our existing tables?

No, Tom is right.  This should not be a ReST format.  For one thing,
the user may just want the extra lines and any escaping/formatting
would get in their way.

And what do you mean by "native?"  Border 0?  Border 1?  Border 2?  I
think that "principle of least surprise" demands that these not change
on a user.
-- 
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: Alvaro Herrera
Date:
Subject: Re: [PATCHES] pg_dump lock timeout
Next
From: Tom Lane
Date:
Subject: Re: Is it really such a good thing for newNode() to be a macro?