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

From Gregory Stark
Subject Re: Proposal: new border setting in psql
Date
Msg-id 874p5321if.fsf@oxford.xeocode.com
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  ("D'Arcy J.M. Cain" <darcy@druid.net>)
Re: Proposal: new border setting in psql  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Alvaro Herrera <alvherre@commandprompt.com> writes:

> Joshua Drake escribió:
>
>> I am trying to understand why we are having a client do this? If you
>> want some other type of output, script it.
>
> Convenience.  If we had real rst output, we could just copy'n paste into
> Trac or other systems.

I'm starting to think D'Arcy's on the right track here.

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.

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

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about
EnterpriseDB'sPostgreSQL training! 


pgsql-hackers by date:

Previous
From: "Hitoshi Harada"
Date:
Subject: Window functions patch v04 for the September commit fest
Next
From: Alvaro Herrera
Date:
Subject: Re: [PATCHES] pg_dump lock timeout