-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Thu, Apr 17, 2008 at 9:53 AM, Alvaro Herrera wrote:
>
> Well, consider that there are going to be 1 or 2 entries in the arrays
> in most cases anyway :-) Well, as far as footers go anyway ... I just
> realized that in all other cases it will ce
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 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
>
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
Hi hackers,
It occurred to me that psql's \z command could benefit from the
addition of some newlines. With any more than one grantee per object,
the output of \z rapidly becomes extremely wide, and very hard to
read.
I'd like to split the output onto one line per grantee. So, instead of this:
"Brendan Jurd" <[EMAIL PROTECTED]> writes:
> It occurred to me that psql's \z command could benefit from the
> addition of some newlines. With any more than one grantee per object,
> the output of \z rapidly becomes extremely wide, and very hard to
> read.
Seems like a good idea now that psql dea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Apr 18, 2008 at 2:37 AM, Tom Lane wrote:
> The function names in the patch need schema-qualification in case
> pg_catalog is not first in the search path.
>
Ah, yes. I should have seen that. Thanks Tom.
New version attached with schema-q
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
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
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 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
>
Gavin Sherry wrote:
> Hi all,
>
> Attached are more fixes.
Applied, thanks.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
"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
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
"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
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
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
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
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
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
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
21 matches
Mail list logo
