Patch applied (yea!).
---
Bruce Momjian wrote:
> Bruce Momjian wrote:
> > Updated patch with clearer documentation that matches the above
> > behavior:
> >
> > ftp://momjian.us/pub/postgresql/mypatches/wrap
>
> I found
Bruce Momjian wrote:
> Updated patch with clearer documentation that matches the above
> behavior:
>
> ftp://momjian.us/pub/postgresql/mypatches/wrap
I found a bug in my patch, particularly related to wrapping to pipes.
Turns out if psql uses the pager internally:
\pset format wra
* Bruce Momjian <[EMAIL PROTECTED]> [080506 11:59]:
> > But one of the interesting things is that psql has an is *interactive*
> > mode (something the GNU utils don't have to worry about). So *when* you
> > choose to figure out your columns is important, and really impacts
> > behaviour too.
> >
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> Am Dienstag, 6. Mai 2008 schrieb Tom Lane:
>> Well, COLUMNS has no hope of tracking on-the-fly changes of window size,
>> which is why the ioctl should take precedence over it.
> Readline changes the value of COLUMNS on the fly.
... from the ioctl's
Peter Eisentraut wrote:
> Am Dienstag, 6. Mai 2008 schrieb Tom Lane:
> > Well, COLUMNS has no hope of tracking on-the-fly changes of window size,
> > which is why the ioctl should take precedence over it.
>
> Readline changes the value of COLUMNS on the fly.
Yes, but my patch grabs COLUMNS before
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I just looked at coreutils-6.9 and 5.97 and neither manual has a mention
> of COLUMNS. Seems this is some Debian manual addition or something. I
> don't see it on Ubuntu 7.10 either.
You're looking in the wrong place. See "info ls".
Tom Lane wrote:
> Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> > But one of the interesting things is that psql has an is *interactive*
> > mode (something the GNU utils don't have to worry about). So *when* you
> > choose to figure out your columns is important, and really impacts
> > behaviour to
Am Dienstag, 6. Mai 2008 schrieb Tom Lane:
> Well, COLUMNS has no hope of tracking on-the-fly changes of window size,
> which is why the ioctl should take precedence over it.
Readline changes the value of COLUMNS on the fly.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
T
Aidan Van Dyk wrote:
> I have to admit to using the COLUMNS=... trick myself.
>
> I do have COLUMNS exported in my terminal, and often to stuff like:
>
> ls -C | less
>
> and I expect it to wrap at $COLUMNS (my terminal width) in my pager.
>
> And since the GNU coreutils is pretty consis
Aidan Van Dyk <[EMAIL PROTECTED]> writes:
> But one of the interesting things is that psql has an is *interactive*
> mode (something the GNU utils don't have to worry about). So *when* you
> choose to figure out your columns is important, and really impacts
> behaviour too.
Well, COLUMNS has no h
* Bruce Momjian <[EMAIL PROTECTED]> [080506 10:56]:
> What logic is there that GNU ls honors COLUMNS only in non-terminal
> output? And the use of COLUMNS isn't even documented in the GNU ls
> manual page. And BSD ls honors COLUMNS only for terminal output when
> the ioctl fails(). It is hard
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > FYI, I looked into 'ls -C' hanlding a little more and ls (GNU coreutils)
> > 5.97 honors COLUMNS _only_ in file/pipe output, not for screen output.
> > What the C code does is to read COLUMNS, then overwrite that value with
Gregory Stark wrote:
> "Tom Lane" <[EMAIL PROTECTED]> writes:
>
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> >> Are others OK with $COLUMNS controlling screen output and file/pipe, or
> >> perhaps COLUMNS controlling only file/pipe, as GNU ls does? I have
> >> heard a few people say they only
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
>> Are others OK with $COLUMNS controlling screen output and file/pipe, or
>> perhaps COLUMNS controlling only file/pipe, as GNU ls does? I have
>> heard a few people say they only want \pset columns to control
>>
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> FYI, I looked into 'ls -C' hanlding a little more and ls (GNU coreutils)
> 5.97 honors COLUMNS _only_ in file/pipe output, not for screen output.
> What the C code does is to read COLUMNS, then overwrite that value with
> ioctl() if it works.
Well sa
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Are others OK with $COLUMNS controlling screen output and file/pipe, or
> > perhaps COLUMNS controlling only file/pipe, as GNU ls does? I have
> > heard a few people say they only want \pset columns to control
> > file/pipe.
>
> I ag
Bruce Momjian wrote:
> Gregory Stark wrote:
> > "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> >
> > > OK, so COLUMNS should take precedence. I assume this is going to
> > > require us to read the COLUMNS enviroment variable in psql _before_
> > > readline sets it, and that COLUMNS will only affec
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Are others OK with $COLUMNS controlling screen output and file/pipe, or
> perhaps COLUMNS controlling only file/pipe, as GNU ls does? I have
> heard a few people say they only want \pset columns to control
> file/pipe.
I agree with the latter. Anyone w
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > OK, so COLUMNS should take precedence. I assume this is going to
> > require us to read the COLUMNS enviroment variable in psql _before_
> > readline sets it, and that COLUMNS will only affect screen output, like
> > ioctl()
Bryce Nesbitt wrote:
>
> > OK, so COLUMNS should take precedence. I assume this is going to
> > require us to read the COLUMNS environment variable in psql _before_
> > readline sets it, and that COLUMNS will only affect screen output, like
> > ioctl(). Is that consistent?
> >
> This whole th
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> OK, so COLUMNS should take precedence. I assume this is going to
> require us to read the COLUMNS enviroment variable in psql _before_
> readline sets it, and that COLUMNS will only affect screen output, like
> ioctl(). Is that consistent?
What are
OK, so COLUMNS should take precedence. I assume this is going to
require us to read the COLUMNS enviroment variable in psql _before_
readline sets it, and that COLUMNS will only affect screen output, like
ioctl(). Is that consistent?
This whole thing is confusing enough at the point, I thin
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> > > Peter Eisentraut wrote:
> > > > Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> > > > > We do look at COLUMNS if the ioctl() fails, but not for file/pipe
> > > > > output.
> > > >
> > >
Bryce Nesbitt wrote:
> Tom Lane wrote:
> > Well, personally I haven't read the core code yet, since it's not commit
> > fest yet ;-). I don't know whether there are any issues there, but it
> > wouldn't surprise me given the number of issues in the control code.
> >
> > regar
Tom Lane wrote:
Well, personally I haven't read the core code yet, since it's not commit fest
yet ;-). I don't know whether there are any issues there, but it wouldn't
surprise me given the number of issues in the control code.
regards, tom lane
I'm biased because
Gregory Stark wrote:
[No I wasn't thinking of that, that's an interesting case too though I think
we might need to think a bit harder about cases that wrap poorly. If you have
long column headings we could wrap those too. But what if you have enough
space for just a few characters per column and
Bryce Nesbitt <[EMAIL PROTECTED]> writes:
> AFIK, the only thing that's controversial about the patch is how to turn
> it on and off -- the actual core code appears to be inflaming no
> passions. And it's the core code that presents merge issues.
Well, personally I haven't read the core code ye
Tom Lane wrote:
This patch seems sufficiently controversial that "commit now" is the
very last thing that should happen to it.
I suggest committing the PrintTable stuff and not worrying about whether
that breaks the wrap patch.
regards, tom lane\
AFIK, the only thing
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> This patch is blocking other work -- for instance, the PrintTable API
> and two patches that depend on it.
> Could we get the main hunks committed soon, with the policy bits
> stripped out? That way, discussion on the behavior can continue until
> we r
Peter Eisentraut wrote:
> Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> > Peter Eisentraut wrote:
> > > Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> > > > We do look at COLUMNS if the ioctl() fails, but not for file/pipe
> > > > output.
> > >
> > > This is quite a useless complicatio
This patch is blocking other work -- for instance, the PrintTable API
and two patches that depend on it.
Could we get the main hunks committed soon, with the policy bits
stripped out? That way, discussion on the behavior can continue until
we reach an agreement, and others can work on other patch
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
>> > Peter Eisentraut wrote:
>> > > Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
>> > > > We do look at COLUMNS if the ioctl() fails, but not for file/pipe
>> > > > out
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> Peter Eisentraut wrote:
> > Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> > > We do look at COLUMNS if the ioctl() fails, but not for file/pipe
> > > output.
> >
> > This is quite a useless complication. Readline uses exactly the same
> >
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>>
>> > We do look at COLUMNS if the ioctl() fails, but not for file/pipe
>> > output.
>>
>> Yeah, it looks like your most recent patch still has the bug that if the user
>> specifie
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > Gregory Stark wrote:
> >> > Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
> >> > but that seems confusing.
> >>
> >> We could always read COLUMNS early on before readline is initialized and
> >> s
Peter Eisentraut wrote:
> Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> > We do look at COLUMNS if the ioctl() fails, but not for file/pipe
> > output.
>
> This is quite a useless complication. Readline uses exactly the same ioctl()
> call to determine the columns, so if ioctl() were to f
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
>> We do look at COLUMNS if the ioctl() fails, but not for file/pipe
>> output.
>
> This is quite a useless complication. Readline uses exactly the same ioctl()
> call to determine the columns, so
Am Dienstag, 29. April 2008 schrieb Bruce Momjian:
> We do look at COLUMNS if the ioctl() fails, but not for file/pipe
> output.
This is quite a useless complication. Readline uses exactly the same ioctl()
call to determine the columns, so if ioctl() were to fail, then COLUMNS would
be unset or
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> > Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
>> > but that seems confusing.
>>
>> We could always read COLUMNS early on before readline is initialized and
>> stash
>> the value away in a variable.
Gregory Stark wrote:
> > Now, we could get fancy and honor $COLUMNS only in non-interactive mode,
> > but that seems confusing.
>
> We could always read COLUMNS early on before readline is initialized and stash
> the value away in a variable. But...
>
> We would only look at COLUMNS if the ioctl
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>> "Bryce Nesbitt" <[EMAIL PROTECTED]> writes:
>>
>> > Unless they are in the habit of doing:
>> >
>> > # COLUMNS=$COLUMNS ls -C |cat
>>
>> Some of us are actually in the habit of doing that because it's easier to use
>> the stan
Gregory Stark wrote:
> "Bryce Nesbitt" <[EMAIL PROTECTED]> writes:
>
> > Unless they are in the habit of doing:
> >
> > # COLUMNS=$COLUMNS ls -C |cat
>
> Some of us are actually in the habit of doing that because it's easier to use
> the standard interface than remembering the different command-l
"Bryce Nesbitt" <[EMAIL PROTECTED]> writes:
> Unless they are in the habit of doing:
>
> # COLUMNS=$COLUMNS ls -C |cat
Some of us are actually in the habit of doing that because it's easier to use
the standard interface than remembering the different command-line option for
each command. I quite
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
I don't see that behavior here on Ubuntu 7.10:
$ COLUMNNS=120 ls -C |cat
archive cdinitrd lost+found proc srv usr
basement.usr dev initrd.img media root sys var
bin
Bruce Momjian <[EMAIL PROTECTED]> writes:
> I don't see that behavior here on Ubuntu 7.10:
> $ COLUMNNS=120 ls -C |cat
> archive cdinitrd lost+found proc srv usr
> basement.usr dev initrd.img media root sys var
> bin etc laptop
Bruce Momjian wrote:
> Oops, Alvaro pointed out I typo'ed the variable name COLUMNS as
> COLUMNNS. I see now that 'ls -C' does honor columns. See my later
> posting about '\pset wrapped 0' as a special case where we could honor
> the ioctl/COLUMNS case.
>
> My real confusion is this:
>
> $
* Bruce Momjian <[EMAIL PROTECTED]> [080426 09:44]:
> Why does the first 'ls' not honor columns while the second does? How
> does 'ls' detect that the COLUMNS=120 is somehow different from the
> default COLUMNS value?
I would hazard a guess that COLUMNS isn't "exported" from your
shell environme
Bruce Momjian wrote:
> Gregory Stark wrote:
> I don't see that behavior here on Ubuntu 7.10:
>
> $ COLUMNNS=120 ls -C |cat
> archive cdinitrd lost+found proc srv usr
> basement.usr dev initrd.img media root sys var
> bin etc laptop
Gregory Stark wrote:
>
> [Just when I thought I was out, they pull me back in -- argh, I'm weak]
>
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > FYI, ls -C actually wraps to 72(?) unless you specify another width,
>
> I told you exactly what ls did, at least GNU ls. It uses -w if specifi
[Just when I thought I was out, they pull me back in -- argh, I'm weak]
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> FYI, ls -C actually wraps to 72(?) unless you specify another width,
I told you exactly what ls did, at least GNU ls. It uses -w if specified, if
not then it uses the ioctl if
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > Obviously you have expections of how wrapping should behave. Please
> > name me an application that has a wrapped mode that has the output to a
> > file wrap based on the screen width? It isn't 'ls -C'.
>
> Why would we need to imitate what
>>> On Fri, Apr 25, 2008 at 3:14 PM, in message
<[EMAIL PROTECTED]>, "Brendan
Jurd"
<[EMAIL PROTECTED]> wrote:
> If the user hasn't specified any format at all, then it's fine to
play
> guessing games and try to select the best format automatically for
> him, based on factors like the destinati
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 5:21 AM, Bruce Momjian
wrote:
> Obviously you have expections of how wrapping should behave. Please
> name me an application that has a wrapped mode that has the output to a
> file wrap based on the screen width? It isn't
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> There is no point in doing things in a certain way just because others
> do the same. Are you going to argue that we need to make the server
> crash from time to time because other systems do that too?
> We came up with dollar quoting which is a comple
Bruce Momjian escribió:
> Obviously you have expections of how wrapping should behave. Please
> name me an application that has a wrapped mode that has the output to a
> file wrap based on the screen width? It isn't 'ls -C'.
Why would we need to imitate what other apps do? What we need to
inve
Brendan Jurd wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Sat, Apr 26, 2008 at 4:46 AM, Gregory Stark wrote:
> > If you specify format=wrapped and get something other than wrapped it's a
> > bug
> > and people will undoubtedly report it as such.
> >
>
> Agree. If I tell ps
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Apr 26, 2008 at 4:46 AM, Gregory Stark wrote:
> If you specify format=wrapped and get something other than wrapped it's a bug
> and people will undoubtedly report it as such.
>
Agree. If I tell psql that I want wrapped output and it gives
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
>> I think the people wanting wrapped to control file/pipe don't want it as
>> the default, but want _some_ way of getting wrapped output into a file.
>
> Let me add that the patch as it was posted does not have wrapping
> affecting file/pipe output unle
Bruce Momjian wrote:
> Alvaro Herrera wrote:
> > Bruce Momjian escribi?:
> >
> > > Have a 'format=auto' mode that does aligned/wrapped/expanded, but only
> > > for screen output --- file/pipe would still use aligned. And have
> > > 'format=wrapped' affect file/pipe by requiring the user to specif
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
>
> > Have a 'format=auto' mode that does aligned/wrapped/expanded, but only
> > for screen output --- file/pipe would still use aligned. And have
> > 'format=wrapped' affect file/pipe by requiring the user to specify the
> > width, or use a default
On Fri, 25 Apr 2008 10:45:01 -0400
Alvaro Herrera <[EMAIL PROTECTED]> wrote:
> I have a different question. Why are we mixing file and pipe
> output? I think the use cases are different and perhaps we should
> use different defaults.
>
> For example, most people I've seen writing shell script
Bruce Momjian escribió:
> Have a 'format=auto' mode that does aligned/wrapped/expanded, but only
> for screen output --- file/pipe would still use aligned. And have
> 'format=wrapped' affect file/pipe by requiring the user to specify the
> width, or use a default of 72.
I have a different questi
Bruce Momjian wrote:
> 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.
I haven't h
* Bruce Momjian <[EMAIL PROTECTED]> [080424 23:14]:
> 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
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>>> On what platforms does ioctl() fail?
>
>> On ssh for example.
>
> That'd certainly be a showstopper if true, but it seems to be okay for
> me. ssh'ing from an xte
Bruce Momjian wrote:
For example, if I want to send wide psql output in email, right now I
just send it wide or use \x. With 'wrapped' I can set it to 72 columns
and get something I can email to people. I could copy it from my
screen, but if the output is more than a screen full it is much har
Joshua D. Drake wrote:
> Bruce Momjian wrote:
> > 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
Bruce Momjian wrote:
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.
+1
We have discussed having a formatting mo
Bruce Momjian wrote:
> > 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 thi
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> 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 ju
Gregory Stark <[EMAIL PROTECTED]> writes:
> "Alvaro Herrera" <[EMAIL PROTECTED]> writes:
>> On what platforms does ioctl() fail?
> On ssh for example.
That'd certainly be a showstopper if true, but it seems to be okay for
me. ssh'ing from an xterm window, and running psql on the remote side,
I c
"Bruce Momjian" <[EMAIL PROTECTED]> 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"?
> I can't
"Alvaro Herrera" <[EMAIL PROTECTED]> writes:
> On what platforms does ioctl() fail?
On ssh for example.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's RemoteDBA services!
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org
Alvaro Herrera wrote:
> Bruce Momjian escribi?:
> > Peter Eisentraut wrote:
> > >
> > > I think it is best not to look at $COLUMNS at all. If the output is to a
> > > terminal, then use ioctl to query the terminal. And provide a \pset
> > > command
> > > to set a width explicitly, which can a
Bruce Momjian escribió:
> Peter Eisentraut wrote:
> >
> > I think it is best not to look at $COLUMNS at all. If the output is to a
> > terminal, then use ioctl to query the terminal. And provide a \pset
> > command
> > to set a width explicitly, which can apply in all cases.
>
> Yes, that is
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > I think the API in the patch is the best I am going to do to keep
> > everyone happy --- 'wrapped' doesn't affect file/pipe output unless you
> > also tell it the width you want. Most interactive users are going to
> > set '
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Greg's suggestion is to use $COLUMNS if the width can't be determined
> > because the output is not directly to the screen. ?$COLUMNS is updated
> > by many shells.
>
> I think it is best not to look at $COLUMNS at all. If the output is to a
> t
Bruce Momjian wrote:
> Greg's suggestion is to use $COLUMNS if the width can't be determined
> because the output is not directly to the screen. $COLUMNS is updated
> by many shells.
I think it is best not to look at $COLUMNS at all. If the output is to a
terminal, then use ioctl to query the t
Bruce Momjian wrote:
> 'ls' and 'ls | more' generate different outputs, and I have never heard
> anyone call that "bunk".
bunk
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> I think the API in the patch is the best I am going to do to keep
> everyone happy --- 'wrapped' doesn't affect file/pipe output unless you
> also tell it the width you want. Most interactive users are going to
> set 'wrapped' and never set the width
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > 'ls' and 'ls | more' generate different outputs, and I have never heard
> > anyone call that "bunk".
>
> The analogue of that would be making psql default to wrapped mode if isatty is
> true and normal mode if it's false. I
Aidan Van Dyk wrote:
-- Start of PGP signed section.
> * Bruce Momjian <[EMAIL PROTECTED]> [080424 14:37]:
>
> > I am confused exactly what people want changed in the patch. Some want
> > no control over wrapping in file output, and others want $COLUMN to
> > control column file output. The onl
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> 'ls' and 'ls | more' generate different outputs, and I have never heard
> anyone call that "bunk".
The analogue of that would be making psql default to wrapped mode if isatty is
true and normal mode if it's false. I wouldn't be entirely against that b
* Bruce Momjian <[EMAIL PROTECTED]> [080424 14:37]:
> I am confused exactly what people want changed in the patch. Some want
> no control over wrapping in file output, and others want $COLUMN to
> control column file output. The only person I am seeing code from is
> Greg Stark, but I think mos
bruce wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > You are going to need to find community members who support your
> > > analysis if you want to make any headway in changing the patch.
> >
> > Let's turn that around, shall we? I think at this point it's *you*
> >
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > You are going to need to find community members who support your
> > analysis if you want to make any headway in changing the patch.
>
> Let's turn that around, shall we? I think at this point it's *you*
> that are standing alone and
Bruce Momjian <[EMAIL PROTECTED]> writes:
> You are going to need to find community members who support your
> analysis if you want to make any headway in changing the patch.
Let's turn that around, shall we? I think at this point it's *you*
that are standing alone and need to find someone who ag
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
>
> > My point is that we should do what most people _expect_, and the
> > majority of people here have stated they don't think wrap should modify
> > the file output _by_ _default_.
> >
> > People who want a specific width for fil
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> My point is that we should do what most people _expect_, and the
> majority of people here have stated they don't think wrap should modify
> the file output _by_ _default_.
>
> People who want a specific width for files should be setting their
> desire
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian <[EMAIL PROTECTED]> writes:
> > > Peter Eisentraut wrote:
> > >> Well, the feature is labeled "psql wraps at window width". If the
> > >> output
> > >> isn't on a window, then it shouldn't wrap.
> >
> > > \pset columns will wrap to the sp
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Peter Eisentraut wrote:
> >> Well, the feature is labeled "psql wraps at window width". If the output
> >> isn't on a window, then it shouldn't wrap.
>
> > \pset columns will wrap to the specified width for file output.
>
> I agree
Gregory Stark wrote:
> >> b) If you dump to a file it will still respect COLUMNS. This might be a bit
> >>weird since bash sets COLUMNS so your file width will be based on the
> >> size
> >>of your terminal. But people also do things like COLUMNS=120 psql -o f
> >> ...
> >
> > No, that wi
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Peter Eisentraut wrote:
>> Well, the feature is labeled "psql wraps at window width". If the output
>> isn't on a window, then it shouldn't wrap.
> \pset columns will wrap to the specified width for file output.
I agree with Peter: that's a seriously
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Uh, if you do that I am not sure what the user would want. I duplicated
> what we do with PAGER and unless there is a clear mandate I think we
> should keep the wrapping detection consistent with that; we have gotten
> no complaints. Pager will not
Peter Eisentraut wrote:
> Am Donnerstag, 24. April 2008 schrieb Gregory Stark:
> > b) If you dump to a file it will still respect COLUMNS. This might be a bit
> > ? ?weird since bash sets COLUMNS so your file width will be based on the
> > size of your terminal. But people also do things like COLUM
Am Donnerstag, 24. April 2008 schrieb Gregory Stark:
> b) If you dump to a file it will still respect COLUMNS. This might be a bit
> weird since bash sets COLUMNS so your file width will be based on the
> size of your terminal. But people also do things like COLUMNS=120 psql -o f
> ...
Well, th
Bruce Momjian escribió:
> > b) If you dump to a file it will still respect COLUMNS. This might be a bit
> >weird since bash sets COLUMNS so your file width will be based on the
> > size
> >of your terminal. But people also do things like COLUMNS=120 psql -o f
> > ...
>
> No, that will m
Gregory Stark wrote:
> "Bruce Momjian" <[EMAIL PROTECTED]> writes:
> > Gregory Stark wrote:
> >> Earlier I suggested -- and nobody refuted -- that we should follow the
> >> precedents of ls and man and other tools which need to find the terminal
> >> width: Explicitly set width takes precedence alw
"Bruce Momjian" <[EMAIL PROTECTED]> writes:
> Gregory Stark wrote:
>
>> Earlier I suggested -- and nobody refuted -- that we should follow the
>> precedents of ls and man and other tools which need to find the terminal
>> width: Explicitly set width takes precedence always, if it's not explicitly
1 - 100 of 105 matches
Mail list logo
