), 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
3) The usual version mismatch warning 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.po
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 "
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
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
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:
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, dar
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
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
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
But
it may 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
14 matches
Mail list logo