Re: Proposed patch - psql wraps at window width - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: Proposed patch - psql wraps at window width
Date
Msg-id 200804250314.m3P3E3602745@momjian.us
Whole thread Raw
In response to Re: Proposed patch - psql wraps at window width  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Proposed patch - psql wraps at window width
Re: Proposed patch - psql wraps at window width
Re: Proposed patch - psql wraps at window width
Re: Proposed patch - psql wraps at window width
List pgsql-hackers
Gregory Stark wrote:
> "Bruce Momjian" <bruce@momjian.us> writes:
> 
> > I am not excited about 'wrapped-interactive' and 'wrapped-all' formats. 
> > Do you have some other idea in mind?
> 
> Some other idea for the name of it? Not particularly. I like your later
> suggestion of "auto". Perhaps just "wrapped" and "auto"?

Well, I was going to bring up changes to the default after the patch was
applied but I will bring it up now.  I think there is some real
attractivness to having long values wrap to fit on your screen in
interactive mode.  In fact, it is hard to justify our current
interactive behavior of a row just overflowing the screen width and
moving to the next line.  We have gotten used to it, but it is certainly
not very user-friendly.

We have discussed having a formatting mode where aligned output switches
to expanded output when the row is too wide.  One idea would be to
create an 'auto' mode that would display in aligned, or wrapped if that
doesn't fit, or expanded if that doesn't fit.

However, this idea really doesn't help us with the file/pipe idea.  One
crazy idea would be for formatting to take two values, like:
\pset formatting wrapped aligned

where the first is for interactive use and the second is for file/pipe
output.  Now, if they only specify one value, what does that control?

> > I can't think of any cases where we have one setting for interactive and
> > another for all uses.
> 
> In general I don't like such things but it seems to be what you're trying to
> do. And also what Tom seems to be yearning for when he says that it shouldn't
> affect file output. And if we do it we should do it properly and not hobble
> both modes.
> 
> Note that basing it on the window size ioctl doesn't actually dtrt either.
> What you really want is for it to depend on isatty(). If isatty(fout) is true
> then you want to try to take the interactive default even if the ioctl fails.

Yes, we do that now with $COLUMNS.

> Trying to join the two decisions means that nobody will be happy. If you ssh
> in you won't get wrapped format, if you redirect to a file and specify wrapped
> format explicitly you'll be frustrated that you're still not getting it. And
> if you do want those things so you \pset columns you'll find it starts doing
> it even when you -f file.dmp -- which doesn't seem bad to me but it means it
> isn't satisfying your desires.

I think we need to honor $COLUMNS if ioctl() fails.

--  Bruce Momjian  <bruce@momjian.us>        http://momjian.us EnterpriseDB
http://enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Robert Treat
Date:
Subject: Re: MERGE Specification
Next
From: Bruce Momjian
Date:
Subject: Re: Proposed patch - psql wraps at window width