[PATCHES] Coding standards
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, darn it, I sure like //
And my vi is set to:
set sw=4
set ts=4
set expandtab
Because my corporate projects require spaces not tabs.
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
start of a new line, so
! while(--count) {
! lines++;
! lines->ptr = NULL;
! lines->width = 0;
! }
becomes
! while(--count)
! {
! lines++;
! lines->ptr = NULL;
! lines->width = 0;
! }
(with correct indentation anyway)
* Always use tabs, not spaces, to indent. Tabs are 4 spaces wide.
* Don't use double stars in comments.
* "} else" is forbidden too. Use two separate lines.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
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 particular assumption was causing a problem, causing a segfault. I can't be certain, because the multibyte stuff is pretty intense, but I think I nailed it. Thanks for all your comments! -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
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 program that's already running. Personally I often resize the window while psql is running, and I expect that to work. I'm with Peter on this one: we have used ioctl, and nothing else, to determine the vertical window dimension for many years now, to the tune of approximately zero complaints. It's going to take one hell of a strong argument to persuade me that determination of the horizontal dimension should not work exactly the same way. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
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 a way to fix that by decrementing by more than one to shrink a column? I am attaching a new patch with my improved loop. It remembers the previous maximum ratio. No! Performance was not the issue. The out just looked like a jumble onscreen when the line was word wrapped BUT did not fit on the screen anyway. To increase the number of layouts that fit, a co-worker suggested I squeeze out the 2 spaces in each column header. -Bryce
Re: [PATCHES] Proposed patch - psql wraps at window width
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 if the pager should be used. Seems COLUMNS should take precedence over ioctl(), right? Considering that the code to determine the row count is undisputed so far, the column count detection should work the same. That is, we might not need to look at COLUMNS at all. Unless there is a use case for overriding the column count (instead of just turning off the wrapping). I asked the folks over at "Experts Exchange" to test the behavior of the ioctl and $COLUMNS on various platforms. I'd been told that I would face huge problems if a console was resized. But the results were pretty consistent, and nothing had problems with resize: http://www.experts-exchange.com/Programming/Open_Source/Q_23243646.html It appears impossible to override $COLUMNS, on some platforms as the readline call sets it. On many platforms $COLUMNS is null until the call to readline. OSX does not set $COLUMNS at all. -Bryce
Re: [PATCHES] Proposed patch - psql wraps at window width
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 heroic efforts. I agree with Gregory here: I may want to capture either the wrapped or unwrapped output to a file or a pipe. Perhaps the enabling flag for this feature should take a parameter, which is the number of columns to wrap to. I was not bold enough to propose that wrapping be the default behavior for the terminal. And there's no way I'd want wrapping as the default for pipe output. -Bryce
Re: [PATCHES] Proposed patch - psql wraps at window width
"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 spectacularly awful idea for this patch to affect the > output to a file at all. It's a compromise of convenience over principle to allow the default output format to vary but I would still want to have the same set of output formats _available_ to me regardless of whether I'm redirecting to a file or not. Much like ls -C is available even if you're redirecting to a file and -1 is available if you're on a terminal. 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 heroic efforts. I also have the converse problem occasionally. I run everything under emacs and occasionally run into programs which default to awkward output formats. Usually it's not too bad because it's still on a pty but the window width is a particular one which confuses programs. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's RemoteDBA services! -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
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 output to a file at all. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
"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 rows on the screen to determine if the pager should >> be used. Seems COLUMNS should take precedence over ioctl(), right? > > Considering that the code to determine the row count is undisputed so far, > the > column count detection should work the same. That is, we might not need to > look at COLUMNS at all. Unless there is a use case for overriding the column > count (instead of just turning off the wrapping). I do that all the time. I normally am running under an emacs terminal so I don't know what width the ioctl's going to get back but it's unlikely to be right. In any case I may want to format the output to a width narrower than the window because I'm going to narrow it. 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. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support! -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] datum passed to macro which expects a pointer
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) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
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 > hopefully my comments were still useful :-) Oh, yea, certainly. I didn't mention it to the author at first because it was his first patch, and he did a _very_ nice job considering the complexity of what he was doing. -- Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
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 Herrerahttp://www.CommandPrompt.com/ The PostgreSQL Company - Command Prompt, Inc. -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
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 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
> start of a new line, so
>
> ! while(--count) {
> ! lines++;
> ! lines->ptr = NULL;
> ! lines->width = 0;
> ! }
>
> becomes
>
>
> ! while(--count)
> ! {
> ! lines++;
> ! lines->ptr = NULL;
> ! lines->width = 0;
> ! }
>
> (with correct indentation anyway)
>
>
> * Always use tabs, not spaces, to indent. Tabs are 4 spaces wide.
>
> * Don't use double stars in comments.
>
> * We're not in the habit of giving credit in code comments. It gets
> messy fast.
>
> * 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 I wonder if you've introduced this assumption in the other case
> on that code (i.e. when alignment is not 'r'). I'm not seeing any
> checks for multibytes in there, but perhaps I'm missing it.
>
>
> * "} else" is forbidden too. Use two separate lines.
>
> --
> Alvaro Herrerahttp://www.CommandPrompt.com/
> The PostgreSQL Company - Command Prompt, Inc.
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
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
start of a new line, so
! while(--count) {
! lines++;
! lines->ptr = NULL;
! lines->width = 0;
! }
becomes
! while(--count)
! {
! lines++;
! lines->ptr = NULL;
! lines->width = 0;
! }
(with correct indentation anyway)
* Always use tabs, not spaces, to indent. Tabs are 4 spaces wide.
* Don't use double stars in comments.
* We're not in the habit of giving credit in code comments. It gets
messy fast.
* 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 I wonder if you've introduced this assumption in the other case
on that code (i.e. when alignment is not 'r'). I'm not seeing any
checks for multibytes in there, but perhaps I'm missing it.
* "} else" is forbidden too. Use two separate lines.
--
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Multiline privileges in \z
-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-qualification.
Cheers,
BJ
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: http://getfiregpg.org
iD8DBQFIB4Ae5YBsbHkuyV0RAqJVAJ9+h6wZrLT9YFRw3s2E742sg7Yr4wCgvtcq
xK7cTnbiGtfpGGYw5WP4asI=
=hf8W
-END PGP SIGNATURE-
*** src/bin/psql/describe.c
--- src/bin/psql/describe.c
***
*** 482,488 permissionsList(const char *pattern)
"SELECT n.nspname as \"%s\",\n"
" c.relname as \"%s\",\n"
" CASE c.relkind WHEN 'r' THEN '%s'
WHEN 'v' THEN '%s' WHEN 'S' THEN '%s' END as \"%s\",\n"
! " c.relacl as \"%s\"\n"
"FROM pg_catalog.pg_class c\n"
" LEFT JOIN pg_catalog.pg_namespace n ON n.oid =
c.relnamespace\n"
"WHERE c.relkind IN ('r', 'v',
'S')\n",
--- 482,488
"SELECT n.nspname as \"%s\",\n"
" c.relname as \"%s\",\n"
" CASE c.relkind WHEN 'r' THEN '%s'
WHEN 'v' THEN '%s' WHEN 'S' THEN '%s' END as \"%s\",\n"
! "
pg_catalog.array_to_string(c.relacl, chr(10)) as \"%s\"\n"
"FROM pg_catalog.pg_class c\n"
" LEFT JOIN pg_catalog.pg_namespace n ON n.oid =
c.relnamespace\n"
"WHERE c.relkind IN ('r', 'v',
'S')\n",
*** src/test/regress/expected/dependency.out
--- src/test/regress/expected/dependency.out
***
*** 68,86 NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"deptest_pkey" fo
GRANT ALL ON deptest1 TO regression_user2;
RESET SESSION AUTHORIZATION;
\z deptest1
! Access privileges
for database "regression"
! Schema | Name | Type |
Access privileges
!
+--+---+
! public | deptest1 | table |
{regression_user0=arwdxt/regression_user0,regression_user1=a*r*w*d*x*t*/regression_user0,regression_user2=arwdxt/regression_user1}
(1 row)
DROP OWNED BY regression_user1;
-- all grants revoked
\z deptest1
! Access privileges for database "regression"
! Schema | Name | Type | Access privileges
! +--+---+
! public | deptest1 | table | {regression_user0=arwdxt/regression_user0}
(1 row)
-- table was dropped
--- 68,88
GRANT ALL ON deptest1 TO regression_user2;
RESET SESSION AUTHORIZATION;
\z deptest1
! Access privileges for database "regression"
! Schema | Name | Type | Access privileges
! +--+---+
! public | deptest1 | table | regression_user0=arwdxt/regression_user0
!: regression_user1=a*r*w*d*x*t*/regression_user0
!: regression_user2=arwdxt/regression_user1
(1 row)
DROP OWNED BY regression_user1;
-- all grants revoked
\z deptest1
! Access privileges for database "regression"
! Schema | Name | Type |Access privileges
! +--+---+--
! public | deptest1 | table | regression_user0=arwdxt/regression_user0
(1 row)
-- table was dropped
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] [HACKERS] Multiline privileges in \z
"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 deals nicely with multiline output. The function names in the patch need schema-qualification in case pg_catalog is not first in the search path. regards, tom lane -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
[PATCHES] Multiline privileges in \z
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:
Schema | Name | Type |Access privileges
+--+---+-
public | a| table |
{brendanjurd=arwdxt/brendanjurd,foo=arwd/brendanjurd,bar=r/brendanjurd}
public | b| table | {brendanjurd=arwdxt/brendanjurd,foo=arwd/brendanjurd}
(2 rows)
You would get this:
Schema | Name | Type | Access privileges
+--+---+
public | a| table | brendanjurd=arwdxt/brendanjurd
: foo=arwd/brendanjurd
: bar=r/brendanjurd
public | b| table | brendanjurd=arwdxt/brendanjurd
: foo=arwd/brendanjurd
(2 rows)
Because the -BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
ACLs
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: http://getfiregpg.org
iD8DBQFIB3kL5YBsbHkuyV0RAgWQAJ9bcl3bOFozvi9LxRAQN1OwT3t+QgCcCGVq
dcMw3wIBQVPv1nYDBCSRpDA=
=s1eD
-END PGP SIGNATURE-
are stored as an array, the patch to achieve this is trivial (see attached).
Looking forward to your comments.
Added to wiki.
Cheers,
BJ
*** src/bin/psql/describe.c
--- src/bin/psql/describe.c
***
*** 482,488 permissionsList(const char *pattern)
"SELECT n.nspname as \"%s\",\n"
" c.relname as \"%s\",\n"
" CASE c.relkind WHEN 'r' THEN '%s'
WHEN 'v' THEN '%s' WHEN 'S' THEN '%s' END as \"%s\",\n"
! " c.relacl as \"%s\"\n"
"FROM pg_catalog.pg_class c\n"
" LEFT JOIN pg_catalog.pg_namespace n ON n.oid =
c.relnamespace\n"
"WHERE c.relkind IN ('r', 'v',
'S')\n",
--- 482,488
"SELECT n.nspname as \"%s\",\n"
" c.relname as \"%s\",\n"
" CASE c.relkind WHEN 'r' THEN '%s'
WHEN 'v' THEN '%s' WHEN 'S' THEN '%s' END as \"%s\",\n"
! " array_to_string(c.relacl, chr(10))
as \"%s\"\n"
"FROM pg_catalog.pg_class c\n"
" LEFT JOIN pg_catalog.pg_namespace n ON n.oid =
c.relnamespace\n"
"WHERE c.relkind IN ('r', 'v',
'S')\n",
*** src/test/regress/expected/dependency.out
--- src/test/regress/expected/dependency.out
***
*** 68,86 NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index
"deptest_pkey" fo
GRANT ALL ON deptest1 TO regression_user2;
RESET SESSION AUTHORIZATION;
\z deptest1
! Access privileges
for database "regression"
! Schema | Name | Type |
Access privileges
!
+--+---+
! public | deptest1 | table |
{regression_user0=arwdxt/regression_user0,regression_user1=a*r*w*d*x*t*/regression_user0,regression_user2=arwdxt/regression_user1}
(1 row)
DROP OWNED BY regression_user1;
-- all grants revoked
\z deptest1
! Access privileges for database "regression"
! Schema | Name | Type | Access privileges
! +--+---+
! public | deptest1 | table | {regression_user0=arwdxt/regression_user0}
(1 row)
-- table was dropped
--- 68,88
GRANT ALL ON deptest1 TO regression_user2;
RESET SESSION AUTHORIZATION;
\z deptest1
! Access privileges for database "regression"
! Schema | Name | Type | Access privileges
! +--+---+
! public | deptest1 | table | regression_user0=arwdxt/regression_user0
!: regression_user1=a*r*w*d*x*t*/regression_user0
!: regression_user2=arwdxt/regression_user1
(1 row)
DROP OWNED BY regression_user1;
-- all grants revoked
\z deptest1
! Access privileges for database "regression"
! Schema | Name | Type |Access privileges
! +--+---+--
! public | deptest1 | table | regression_user0=arwdxt/regressio
Re: [PATCHES] Proposed patch - psql wraps at window width
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 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 --- "!" was too close to "|"
> > to be easily recognized. (Did you update your patch to use ":". I
> > didn't see "!" in your patch.)
> Nice! I'll merge with my current version. As you note I changed to ":".
Good, I thought so.
> 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 a way to fix that by decrementing
by more than one to shrink a column? I am attaching a new patch with my
improved loop. It remembers the previous maximum ratio.
> I have tested on several unix flavors, but not on Windows or cygwin.
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?
--
Bruce Momjian <[EMAIL PROTECTED]>http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Index: doc/src/sgml/ref/psql-ref.sgml
===
RCS file: /cvsroot/pgsql/doc/src/sgml/ref/psql-ref.sgml,v
retrieving revision 1.199
diff -c -c -r1.199 psql-ref.sgml
*** doc/src/sgml/ref/psql-ref.sgml 30 Mar 2008 18:10:20 - 1.199
--- doc/src/sgml/ref/psql-ref.sgml 17 Apr 2008 14:05:39 -
***
*** 1513,1519
Sets the output format to one of unaligned,
! aligned, html,
latex, or troff-ms.
Unique abbreviations are allowed. (That would mean one letter
is enough.)
--- 1513,1520
Sets the output format to one of unaligned,
! aligned, wrapped,
! html,
latex, or troff-ms.
Unique abbreviations are allowed. (That would mean one letter
is enough.)
***
*** 1525,1531
is intended to create output that might be intended to be read
in by other programs (tab-separated, comma-separated).
Aligned mode is the standard, human-readable,
! nicely formatted text output that is default. The
HTML and
LaTeX modes put out tables that are intended to
be included in documents using the respective mark-up
--- 1526,1535
is intended to create output that might be intended to be read
in by other programs (tab-separated, comma-separated).
Aligned mode is the standard, human-readable,
! nicely formatted text output that is default.
! Wrapped is like aligned but wraps
! the output to fit the screen's width, based on the environment
! variable COLUMNS or the autodetected width. The
HTML and
LaTeX modes put out tables that are intended to
be included in documents using the respective mark-up
***
*** 2708,2713
--- 2712,2730
+ COLUMNS
+
+
+
+ The character width to wrap output in wrapped format
+ mode. Many shells automatically update COLUMNS when
+ a window is resized. If not set the screen width is automatically
+ detected, if possible.
+
+
+
+
+
PAGER
Index: src/bin/psql/command.c
===
RCS file: /cvsroot/pgsql/src/bin/psql/command.c,v
retrieving revision 1.186
diff -c -c -r1.186 command.c
*** src/bin/psql/command.c 1 Jan 2008 19:45:55 - 1.186
--- src/bin/psql/command.c 17 Apr 2008 14:05:39 -
***
*** 1526,1531
--- 1526,1534
case PRINT_ALIGNED:
return "aligned";
break;
+ case PRINT_WRAP:
+ return "wrapped";
+ break;
case PRINT_HTML:
return "html";
break;
***
*** 1559,1564
--- 1562,1569
popt->topt.format = PRINT_UNALIGNED;
else if (pg_strncasecmp("aligned", value, vallen) == 0)
popt->topt.format = PRINT_ALIGNED;
+ else if (pg_strncasecmp("wrapped", value, vallen) == 0)
+ popt->topt
Re: [PATCHES] Proposed patch - psql wraps at window width
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 > be used. Seems COLUMNS should take precedence over ioctl(), right? Considering that the code to determine the row count is undisputed so far, the column count detection should work the same. That is, we might not need to look at COLUMNS at all. Unless there is a use case for overriding the column count (instead of just turning off the wrapping). -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] Proposed patch - psql wraps at window width
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 --- "!" was too close to "|" > to be easily recognized. (Did you update your patch to use ":". I > didn't see "!" in your patch.) I think we should use a different separator when there is an actual newline in the data. Currently we have a : there, so using a : here is probably not the best idea. -- Alvaro Herrerahttp://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
Re: [PATCHES] printTable API (was: Show INHERIT in \du)
-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 certainly be the wrong thing to > do :-) Still, perhaps a integer count is better? > I oscillated between using an integer and a pointer for ->header and - ->cell while I was writing the code. In the end I went with pointer simply because it makes the iterations nicer looking, and there's a symmetry in having the "first item" and "last item" pointers be the same type. If there's some technical reason that integers would be better, I'll all ears, but from an aesthetic/code readability perspective I like the pointer. > > Brendan Jurd escribió: > > What is it about the extra fields that makes you unhappy? > > I don't know if "unnecessarity" is a word, but I hope you get what I > mean :-) Since the footers list is usually pretty short, you could make an argument for dropping the "last footer" pointer and just iterating through the list to find the last element every time you want to do something with footers. And to do that, you'd have to declare a temporary pointer inside the AddFooter function anyway, so you're not getting rid of the pointer so much as making it slightly more transient. All that having been said, C isn't my native language. So if the pointer is indeed wasteful I'm happy to cede to the wisdom of more experienced C coders. Cheers, BJ -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) Comment: http://getfiregpg.org iD8DBQFIBw7m5YBsbHkuyV0RAv4IAJ0cKrziZpNWkVV7LxFhlV/V5L0pJACfUtZ+ cVbcjL1e89j21JDZJBVdBqw= =Nzr+ -END PGP SIGNATURE- -- Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-patches
