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: