Bruce Momjian wrote:
> > I think it's a bad idea to use the same " : " separator in the two last
> > cases. They are different and they should be displayed differently.
>
> I confirmed with Alvaro that he didn't notice the first uses a colon and
> the second a semicolon, so he is OK.
FYI, I adde
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > ! fputs(string_done ? "
> > " : " ; ", fout);
> > ! }
> > }
>
> I think it's a bad idea to use the same " : " sepa
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > ! /* print a divider, middle columns only
> > */
> > ! if ((j + 1) % col_count)
> > {
> > ! if (opt_
Bruce Momjian wrote:
> ! /* print a divider, middle columns only
> */
> ! if ((j + 1) % col_count)
> {
> ! if (opt_border == 0)
> !
Bryce Nesbitt wrote:
> 1) "\pset columns XX" should make it clear that's for file output only.
OK, docs updated.
> 2) There's an extra space, which breaks \pset border 2
>
> 717c717
> < fputc(' ', fout);;
> ---
> > fput
Bryce Nesbitt wrote:
> The newline handling code was, by far, the most complex part of this
> patch. While I think it would be nicer to "filter up" past the newline,
> I just don't see this as a common need. Large text fields with newlines
> are difficult to really view in psql anyway, and the
1) "\pset columns XX" should make it clear that's for file output only.
2) There's an extra space, which breaks \pset border 2
717c717
< fputc(' ', fout);;
---
> fputc(' ', fout);
842c842
<
The newline handling code was, by far, the most complex part of this
patch. While I think it would be nicer to "filter up" past the newline,
I just don't see this as a common need. Large text fields with newlines
are difficult to really view in psql anyway, and they are likely to be
the longe
Bryce Nesbitt wrote:
> Bruce Momjian wrote:
> > I don't think you need to do that to get it applied --- there is nothing
> > windows-specific in your code.
> >
> > Is this ready to be applied? Do you want to send a final update or are
> > you still testing?
> >
> Looks good, but I suggest addin
On Fri, 18 Apr 2008 17:21:26 +0100
Gregory Stark <[EMAIL PROTECTED]> wrote:
> "Bryce Nesbitt" <[EMAIL PROTECTED]> writes:
>
> > I asked the folks over at "Experts Exchange" to test the behavior
> > of the ioctl
>
> I always thought that was a joke domain name, like Pen Island.com.
>
Its not an
"Bryce Nesbitt" <[EMAIL PROTECTED]> writes:
> I asked the folks over at "Experts Exchange" to test the behavior of the ioctl
I always thought that was a joke domain name, like Pen Island.com.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
Ask me about EnterpriseDB's Po
Peter Eisentraut wrote:
Bruce Momjian wrote:
I checked the use of COLUMNS and it seems bash updates the environment
variable when a window is resized. I added ioctl(TIOCGWINSZ) if COLUMNS
isn't set. We already had a call in print.c for detecting the
number of rows on the screen to determine
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Bryce Nesbitt <[EMAIL PROTECTED]> writes:
>> I checked the use of COLUMNS and it seems bash updates the
>> environment
>> variable when a window is resized.
>
> [ Please get rid of the HTML formatting ... ]
>
> Bash can update the environment all it wa
Peter Eisentraut wrote:
Bruce Momjian wrote:
I checked the use of COLUMNS and it seems bash updates the environment
variable when a window is resized. I added ioctl(TIOCGWINSZ) if COLUMNS
isn't set. We already had a call in print.c for detecting the
number of rows on the screen to determin
Alvaro Herrera wrote:
* Don't lose warning comments like this one (unless you've removed the
assumption of course)
/*
* Assumption: This code used only on strings
* without multibyte characters, otherwise
* this_line->width < strlen(this_ptr) and we get
* an overflow
*/
In fact, that part
Bryce Nesbitt <[EMAIL PROTECTED]> writes:
> I checked the use of COLUMNS and it seems bash updates the
> environment
> variable when a window is resized.
[ Please get rid of the HTML formatting ... ]
Bash can update the environment all it wants, but that will not affect
what is seen by a pro
Bruce Momjian wrote:
I also found that for hugely wide output it was better to give up (do
nothing), rather than mangle the output in a futile attempt to squash it
to the window width. So there is one more clause in the wrapping if.
Was it because of performance? I have
Peter Eisentraut wrote:
Bruce Momjian wrote:
I checked the use of COLUMNS and it seems bash updates the environment
variable when a window is resized. I added ioctl(TIOCGWINSZ) if COLUMNS
isn't set. We already had a call in print.c for detecting the
number of rows on the screen
It would be a spectacularly awful idea for this patch to affect the
output to a file at all.
.
It sucks to run a program, decide you want to capture that output and find you
get something else. It *really* sucks to find there's just no way to get the
same output short of
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Also, how would you suggest figuring the width to use for output going to a
>> file? ioctl is irrelevant in that case, imho it should just default to 80
>> columns if COLUMNS is unset.
>
> It would be a spectacu
Gregory Stark <[EMAIL PROTECTED]> writes:
> Also, how would you suggest figuring the width to use for output going to a
> file? ioctl is irrelevant in that case, imho it should just default to 80
> columns if COLUMNS is unset.
It would be a spectacularly awful idea for this patch to affect the
ou
"Peter Eisentraut" <[EMAIL PROTECTED]> writes:
> Bruce Momjian wrote:
>> I checked the use of COLUMNS and it seems bash updates the environment
>> variable when a window is resized. I added ioctl(TIOCGWINSZ) if COLUMNS
>> isn't set. We already had a call in print.c for detecting the
>> number of
Alvaro Herrera wrote:
> Bruce Momjian wrote:
> >
> > Alvaro is correct. I made most or all of these adjustments in the
> > updated version I posted yesterday.
>
> Doh. I didn't realize you had posted a new version :-(
>
> People is complaining here that we don't teach people here anyway, so
>
Bruce Momjian wrote:
>
> Alvaro is correct. I made most or all of these adjustments in the
> updated version I posted yesterday.
Doh. I didn't realize you had posted a new version :-(
People is complaining here that we don't teach people here anyway, so
hopefully my comments were still useful
Alvaro is correct. I made most or all of these adjustments in the
updated version I posted yesterday.
---
Alvaro Herrera wrote:
> Bryce Nesbitt wrote:
> > I've attached a patch, against current 8.4 cvs, which optionally set
Bryce Nesbitt wrote:
> I've attached a patch, against current 8.4 cvs, which optionally sets a
> maximum width for psql output:
Some random comments:
* Don't use C++ style comments (//). Some compilers don't like these.
* Beware of brace position: we use braces on their own, indented at the
Bryce Nesbitt wrote:
>
>
> Bruce Momjian wrote:
> > I spent time reviewing your patch --- quite impressive. I have attached
> > and updated version with mostly stylistic changes.
> >
> > In testing I found the regression tests were failing because of a divide
> > by zero error (fixed), and a miss
Bruce Momjian wrote:
> I checked the use of COLUMNS and it seems bash updates the environment
> variable when a window is resized. I added ioctl(TIOCGWINSZ) if COLUMNS
> isn't set. We already had a call in print.c for detecting the
> number of rows on the screen to determine if the pager should
>
Bruce Momjian wrote:
> In testing I found the regression tests were failing because of a divide
> by zero error (fixed), and a missing case where the column delimiter has
> to be ":". In fact I now see all your line continuation cases using ":"
> rather than "!". It actually looks better --- "!"
Bruce Momjian wrote:
I spent time reviewing your patch --- quite impressive. I have attached
and updated version with mostly stylistic changes.
In testing I found the regression tests were failing because of a divide
by zero error (fixed), and a missing case where the column delimiter has
to b
Bryce Nesbitt wrote:
> I've attached a patch, against current 8.4 cvs, which optionally sets a
> maximum width for psql output:
>
> # \pset format aligned-wrapped
> # \pset border 2
> # select * from distributors order by did;
> +--++-+---+
Bryce Nesbitt wrote:
> I've attached a patch, against current 8.4 cvs, which optionally sets a
> maximum width for psql output:
I have added this patch to the May commitfest queue,
http://wiki.postgresql.org/wiki/CommitFest:May
--
Alvaro Herrerahttp://www.Comma
I've attached a patch, against current 8.4 cvs, which optionally sets a
maximum width for psql output:
# \pset format aligned-wrapped
# \pset border 2
# select * from distributors order by did;
+--++-+---+
| did |name|
33 matches
Mail list logo
