[PATCHES] Proposed patch - psql wraps at window width

2008-03-05 Thread Bryce Nesbitt
not be 1000% universal. If $COLUMNS is not defined, the code bails to assuming an infinitely wide terminal. I will also backport this to Postgres 8.1, for my own use. Though the code is almost totally different in structure. Bryce Nesbitt City

Re: [PATCHES] Proposed patch - psql wraps at window width

2008-04-16 Thread Bryce Nesbitt
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

Re: [PATCHES] Proposed patch - psql wraps at window width

2008-04-17 Thread Bryce Nesbitt
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

Re: [PATCHES] Proposed patch - psql wraps at window width

2008-04-17 Thread Bryce Nesbitt
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

Re: [PATCHES] Proposed patch - psql wraps at window width

2008-04-17 Thread Bryce Nesbitt
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

Re: [PATCHES] Proposed patch - psql wraps at window width

2008-04-18 Thread Bryce Nesbitt
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

[PATCHES] Coding standards

2008-04-18 Thread Bryce Nesbitt
Alvaro Herrera wrote: People [are] complaining here that we don't teach people here anyway, so hopefully my comments were still useful :-) Yes they are useful. As a new patcher, where should I look for coding standards? How about a little FAQ at the top of the CVS source tree? Though,

Re: [PATCHES] Proposed patch - psql wraps at window width

2008-04-18 Thread Bryce Nesbitt
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

Re: [PATCHES] Proposed patch - psql wraps at window width

2008-04-18 Thread Bryce Nesbitt
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

Re: [PATCHES] Proposed patch - psql wraps at window width

2008-04-20 Thread Bryce Nesbitt
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

Re: [PATCHES] Proposed patch - psql wraps at window width

2008-04-20 Thread Bryce Nesbitt
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

Re: [PATCHES] [HACKERS] Proposed patch - psql wraps at window width

2008-04-28 Thread Bryce Nesbitt
Bruce Momjian wrote: I have updated the documentation for this patch. I consider it ready to apply. I think it is as close to a middle ground as we are going to get. Further adjustment will have to happen when we have more reports from the field. I heard a pretty compelling argument to make

[PATCHES] Patch for psql 8.0, 8.1 and 8.2 backwards compatibility

2008-05-19 Thread Bryce Nesbitt
remains, as this is not a promise of full compatibility. Bryce Nesbitt PS: See also: http://archives.postgresql.org/pgsql-bugs/2005-08/msg00306.php http://unixadmintalk.com/f47/improved-df-psql-backward-compatibility-345293/ http://archives.postgresql.org/pgsql-sql/2008-02/msg00088

Re: [PATCHES] Patch to change psql default banner v6

2008-05-20 Thread Bryce Nesbitt
), or gather the tests into an easily maintainable chunk? The cleaner it is, the more likely future patchers will continue to maintain compatibility. -Bryce Nesbitt -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your