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 a bug in
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 saying
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
file/pipe.
I
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 want \pset columns
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
ioctl()
* 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 to
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 hope
Aidan Van Dyk wrote:
I have to admit to using the COLUMNS=... command 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
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)
To
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 too.
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.
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 we
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
* 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.
For
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
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 you
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 thing is
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(). Is that
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 who is
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 affect screen output,
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 agree with the
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.
regards, tom
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.
This is quite a useless
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
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
output.
This is
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
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 complication. Readline uses
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 reach
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
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 yet,
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
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
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
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 if ioctl()
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 fail,
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
stash
the value away in
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
specifies wrapped there are some
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
ioctl() call
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 often
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-line option for
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 standard interface than
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 for
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. But...
We
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 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
* 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 environment in
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:
$ echo
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 specified, if
not
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 mnt
* 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 hard
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
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 question.
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 scripts
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 of 72.
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 specify the
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 unless you
-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 me
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 psql that I
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
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 completely
-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
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 destination. But
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 other
[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 that
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
set then
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 always, if it's
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 make the
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, the
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 COLUMNS=120
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 work
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 bad idea.
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 will make the
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 with Peter:
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 specified width for file
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
desired width
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 files should be
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
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 need to
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*
that are
* 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 most
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 but 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 only person
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 wouldn't be
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 so it
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 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
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
terminal,
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 'wrapped' and
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 pretty much
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 apply in all
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)
To
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 think of
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 can see
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 just wrapped and
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 things so
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
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 if that
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
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 xterm window, and
1 - 100 of 105 matches
Mail list logo
