Re: [HACKERS] New pg_dump patch -- document statistics collector exception
Apologies. Turns out the name of the relevant setting was changed for
8.3! So a revised patch is attached.
For backing, see:
http://www.postgresql.org/docs/8.3/static/release-8-3.html
" Numerous changes in administrative server parameters...
stats_block_level and stats_row_level are merged into track_counts."
Bruce Momjian wrote:
Bryce Nesbitt wrote:
This is a proposed patch to document disabling the statistics collector
pg_dump activity, and give a bit more visibility to the PGOPTIONS
environment variable supported by libpq.
It is an alternative to the prior patch, which supplied a --no-stats flag.
This is a documentation only patch, not tied to a recent code change.
Patch applied, with spelling correction already noted.
Index: pg_dump.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.514
diff -c -2 -r1.514 pg_dump.c
*** pg_dump.c 18 Jan 2009 20:44:45 - 1.514
--- pg_dump.c 20 Jan 2009 20:47:25 -
***
*** 236,239
--- 236,240
static int outputNoTablespaces = 0;
static int use_setsessauth = 0;
+ static int noStatsCollection = 0;
static struct option long_options[] = {
***
*** 278,281
--- 279,283
{role, required_argument, NULL, 3},
{use-set-session-authorization, no_argument, use_setsessauth, 1},
+ {no-stats, no_argument, noStatsCollection, 1},
{NULL, 0, NULL, 0}
***
*** 430,433
--- 432,437
else if (strcmp(optarg, no-tablespaces) == 0)
outputNoTablespaces = 1;
+ else if (strcmp(optarg, no-stats) == 0)
+ noStatsCollection = 1;
else if (strcmp(optarg, use-set-session-authorization) == 0)
use_setsessauth = 1;
***
*** 613,616
--- 617,629
do_sql_command(g_conn, SET statement_timeout = 0);
+ /*
+ * Disable collection of statistics. pg_dump's activity may be very different
+ * from what you are trying to analyze in the stats tables.
+ */
+ if( noStatsCollection ) {
+ do_sql_command(g_conn, SET stats_block_level = false);
+ do_sql_command(g_conn, SET stats_row_level = false);
+ }
+
/*
* Start serializable transaction to dump consistent data.
***
*** 833,836
--- 846,850
printf(_( -U, --username=NAME connect as specified database user\n));
printf(_( -W, --password force password prompt (should happen automatically)\n));
+ printf(_( --no-stats disable statistics collection (superuser only)\n));
printf(_(\nIf no database name is supplied, then the PGDATABASE environment\n
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New pg_dump patch -- document statistics collector exception
Bruce Momjian wrote: Apologies. Turns out the name of the relevant setting was changed for 8.3! So a revised patch is attached. For backing, see: http://www.postgresql.org/docs/8.3/static/release-8-3.html " Numerous changes in administrative server parameters... stats_block_level and stats_row_level are merged into track_counts." Bryce Nesbitt wrote: We don't want a pg_dump flag; the doc mention is good enough. Doh! Try this one instead. Postgres 8.3 changed the name of the flag mentioned in the doc. Index: ref/pg_dump.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v retrieving revision 1.108 diff -c -2 -r1.108 pg_dump.sgml *** ref/pg_dump.sgml 7 Feb 2009 15:25:51 - 1.108 --- ref/pg_dump.sgml 9 Feb 2009 20:19:48 - *** *** 760,773 library will apply. /para para !The database activity of applicationpg_dump/application is !normally collected by the statistics collector. If this is !undesirable, you can set parameters literalstats_block_level/literal !and literalstats_row_level/literal to false via the !applicationlibpq/ envarPGOPTIONS/envar environment variable, !or via literalALTER USER/literal. /para - /refsect1 --- 760,772 library will apply. /para + para !The database activity of applicationpg_dump/application is normally collected by the !statistics collector. If this is undesirable, you can set parameter !literaltrack_counts/literal to false via envarPGOPTIONS/envar !or the literalALTER USER/literal command. For versions prior to 8.3, set !literalstats_block_level/literal and literalstats_row_level/literal instead. /para /refsect1 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New pg_dump patch -- document statistics collector exception (REVISED PATCH)
Here's a revision (thanks Robert Treat for the spelling corrextion). If there are no other objections, how do I nominate it for consideration? -Bryce Index: pg_dump.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v retrieving revision 1.106 diff -c -2 -r1.106 pg_dump.sgml *** pg_dump.sgml 5 Jan 2009 16:54:36 - 1.106 --- pg_dump.sgml 23 Jan 2009 20:57:36 - *** *** 727,733 termenvarPGDATABASE/envar/term termenvarPGHOST/envar/term termenvarPGPORT/envar/term - termenvarPGUSER/envar/term listitem para --- 727,734 termenvarPGDATABASE/envar/term termenvarPGHOST/envar/term + termenvarPGOPTIONS/envar/term termenvarPGPORT/envar/term + termenvarPGUSER/envar/term listitem para *** *** 735,738 --- 736,740 /para /listitem + /varlistentry /variablelist *** *** 758,761 --- 760,772 library will apply. /para + para +The database activity of applicationpg_dump/application is normally collected by the +statistics collector. If this is undesirable, you can set parameters +literalstats_block_level/literal and literalstats_row_level/literal to false +via the applicationlibpq/application envarPGOPTIONS/envar environment variable, +or via literalALTER USER/literal. + /para + + /refsect1 Index: pg_dumpall.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/pg_dumpall.sgml,v retrieving revision 1.74 diff -c -2 -r1.74 pg_dumpall.sgml *** pg_dumpall.sgml 5 Jan 2009 16:54:36 - 1.74 --- pg_dumpall.sgml 23 Jan 2009 20:57:36 - *** *** 446,449 --- 446,450 varlistentry termenvarPGHOST/envar/term + termenvarPGOPTIONS/envar/term termenvarPGPORT/envar/term termenvarPGUSER/envar/term Index: pg_restore.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v retrieving revision 1.77 diff -c -2 -r1.77 pg_restore.sgml *** pg_restore.sgml 5 Jan 2009 16:54:36 - 1.77 --- pg_restore.sgml 23 Jan 2009 20:57:36 - *** *** 538,541 --- 538,542 varlistentry termenvarPGHOST/envar/term + termenvarPGOPTIONS/envar/term termenvarPGPORT/envar/term termenvarPGUSER/envar/term -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] New pg_dump patch, --no-stats flag, disables sending to statistics collector
This patch adds another flag to pg_dump, this time to disable statistics
collection. This is useful if your don't want pg_dump activity to show
(or clutter) your normal statistics. This may be appropriate for an
organization that regularly dumps a database for backup purposes, but
wants to analyze only the application's database use.
This is patched against CVS HEAD from today, though the code is quite
version independent. This patch is unsolicited, and as far as I know
has not been discussed on the list prior to now.
Comments?
Index: pg_dump.c
===
RCS file: /projects/cvsroot/pgsql/src/bin/pg_dump/pg_dump.c,v
retrieving revision 1.514
diff -c -2 -r1.514 pg_dump.c
*** pg_dump.c 18 Jan 2009 20:44:45 - 1.514
--- pg_dump.c 20 Jan 2009 20:47:25 -
***
*** 236,239
--- 236,240
static int outputNoTablespaces = 0;
static int use_setsessauth = 0;
+ static int noStatsCollection = 0;
static struct option long_options[] = {
***
*** 278,281
--- 279,283
{role, required_argument, NULL, 3},
{use-set-session-authorization, no_argument, use_setsessauth, 1},
+ {no-stats, no_argument, noStatsCollection, 1},
{NULL, 0, NULL, 0}
***
*** 430,433
--- 432,437
else if (strcmp(optarg, no-tablespaces) == 0)
outputNoTablespaces = 1;
+ else if (strcmp(optarg, no-stats) == 0)
+ noStatsCollection = 1;
else if (strcmp(optarg, use-set-session-authorization) == 0)
use_setsessauth = 1;
***
*** 613,616
--- 617,629
do_sql_command(g_conn, SET statement_timeout = 0);
+ /*
+ * Disable collection of statistics. pg_dump's activity may be very different
+ * from what you are trying to analyze in the stats tables.
+ */
+ if( noStatsCollection ) {
+ do_sql_command(g_conn, SET stats_block_level = false);
+ do_sql_command(g_conn, SET stats_row_level = false);
+ }
+
/*
* Start serializable transaction to dump consistent data.
***
*** 833,836
--- 846,850
printf(_( -U, --username=NAME connect as specified database user\n));
printf(_( -W, --password force password prompt (should happen automatically)\n));
+ printf(_( --no-stats disable statistics collection (superuser only)\n));
printf(_(\nIf no database name is supplied, then the PGDATABASE environment\n
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New pg_dump patch, --no-stats flag, disables sending to statistics collector
Bruce Momjian wrote: Jaime Casanova wrote: i haven't looked at the patch nor it's functional use... but from the top of my head jumps a question: is there a reason to not make this the default behaviour? If this is a generally desired feature (and I question that), I think we need a more general solution. I'm not a big fan of flags, preferring good defaults. But I was not bold enough to suggest this as a new default, as someone would probably want the opposite flag. If you're measuring total server load (rather than analyzing an application), you may want to see pg_dump activity. As for a general solution: one could add the ability to inject arbitrary sql just prior to a dump run. That would let someone roll their own by injecting SET stats_block_level = false, or make any other arbitrary settings changes. Or one might slice the statistics collector by role or user (so your 'backup' role would keep a separate tally). On the other hand, the flag's advantage is simplicity and directness. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] New pg_dump patch, --no-stats flag, disables sending to statistics collector
Josh Berkus wrote: I'd argue that it is generally desired (or some convenient workaround) but not urgently so. I'd also argue that if we're going to have a --no-stats flag, it should exist for the other client ultilites as well; if I don't want pg_dump showing up, I probably don't want Vacuum showing up, or various other already-debugged maintenance routines. I'd suggest putting this into the first patch review for 8.5. --Josh As pg_dumpall calls pg_dump, I think this is covered or at least coverable. For vaccum, I've never seen that activity in stats? Can you supply a more specific scenario where routine maintenance is harmfully cluttering the stats table? A specific utility that needs attention? For this feature I'm not so sure about generally desired -- I'll bet most people don't even think about this. The question is among those who DO think about it, what's the best behavior? Can it be argued that excluding pg_dump is generally desirable, for the average use case? If there is not enough demand for a dedicated flag, I may submit a man page patch documenting the Do-It-Yourself solution proposed by Greg Smith, or the one proposed by Tom Lane. G'day -Bryce PS: Note that no respondent on the psql user's lists thought excluding pg_dump was even possible -- so that at least argues for desirability of instructional material :-). -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] New pg_dump patch -- document statistics collector exception
This is a proposed patch to document disabling the statistics collector pg_dump activity, and give a bit more visibility to the PGOPTIONS environment variable supported by libpq. It is an alternative to the prior patch, which supplied a --no-stats flag. This is a documentation only patch, not tied to a recent code change. ? HTML.index ? test.man Index: ref/pg_dump.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/pg_dump.sgml,v retrieving revision 1.106 diff -c -2 -r1.106 pg_dump.sgml *** ref/pg_dump.sgml 5 Jan 2009 16:54:36 - 1.106 --- ref/pg_dump.sgml 21 Jan 2009 01:15:41 - *** *** 727,733 termenvarPGDATABASE/envar/term termenvarPGHOST/envar/term termenvarPGPORT/envar/term - termenvarPGUSER/envar/term listitem para --- 727,734 termenvarPGDATABASE/envar/term termenvarPGHOST/envar/term + termenvarPGOPTIONS/envar/term termenvarPGPORT/envar/term + termenvarPGUSER/envar/term listitem para *** *** 735,738 --- 736,740 /para /listitem + /varlistentry /variablelist *** *** 758,761 --- 760,770 library will apply. /para + para +The database activity of applicationpg_dump/application is normally collected by the statistics collector. +If this is undesirable, you can set parameters literalstats_block_level/literal and literalstats_row_level/literal to false +via the applicationlibpq/ envarPGOPTIONS/envar environment varriable, or via literalALTER USER/literal. + /para + + /refsect1 Index: ref/pg_dumpall.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/pg_dumpall.sgml,v retrieving revision 1.74 diff -c -2 -r1.74 pg_dumpall.sgml *** ref/pg_dumpall.sgml 5 Jan 2009 16:54:36 - 1.74 --- ref/pg_dumpall.sgml 21 Jan 2009 01:15:41 - *** *** 446,449 --- 446,450 varlistentry termenvarPGHOST/envar/term + termenvarPGOPTIONS/envar/term termenvarPGPORT/envar/term termenvarPGUSER/envar/term Index: ref/pg_restore.sgml === RCS file: /projects/cvsroot/pgsql/doc/src/sgml/ref/pg_restore.sgml,v retrieving revision 1.77 diff -c -2 -r1.77 pg_restore.sgml *** ref/pg_restore.sgml 5 Jan 2009 16:54:36 - 1.77 --- ref/pg_restore.sgml 21 Jan 2009 01:15:41 - *** *** 538,541 --- 538,542 varlistentry termenvarPGHOST/envar/term + termenvarPGOPTIONS/envar/term termenvarPGPORT/envar/term termenvarPGUSER/envar/term -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] TODO Item: Allow pg_hba.conf to specify host names along with IP addresses
On Jun 12, 2008, at 12:25 PM, Bruce Momjian wrote: Dickson S. Guedes wrote: Hi all, There is a TODO Item to allow pg_hba.conf to specify host names along with IP addresses. I'd like to work on this feature, if nobody is working too and no objection exists. Please do --- I know of no one working on that. Oooh please do! -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] psql wrapped format default for backslash-d commands
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: Now that psql '\pset format wrapped' is in CVS, we should consider when we want to use 'wrapped' format by default. After experimenting for a bit, I'd say "never". This output format is extremely ugly. Maybe if it had enough smarts not to break in the middle of words ... regards, tom lane Yet, wrapped is the same as aligned, if the lines fit! Ugly to wrap? Yes. Uglier than the sea of pipes you get when aligned output wraps itself? Well I suppose you have to pick your preferred version of ugly. I find it very hard to line up columns when presented with a sea of pipes, and highly annoying to constantly adjust my window width to see a query, especially if only one or two rows are too large. -Bryce PS: it is true, I don't like the missing | bars on the current version. I prefer that the grid cells be fully drawn, even if the contents don't fill the box
Re: [HACKERS] psql wrapped format default for backslash-d commands
Brendan Jurd wrote: I really like the idea of wrapping, but after playing with the format a bit myself, I have to agree with Tom that breaking in the middle of words produces some very nasty output. If the format could be improved to only wrap on word boudaries, that would increase its appeal dramatically. Anybody got a rough idea how difficult it would be to add word-awareness int o the wrapping code? Cheers, BJ It's not that hard to do. I chose not to, when writing the patch, because it makes the result flow over many more lines. And regardless, it pretty much has to cut long words, of which there are many in typical SQL output. And, I hardly ever read actual large blocks of English at the SQL prompt, so: designing for that use case did not float my boat at the time. And, word wrapping messes with the cell contents more than I was comfortable doing. With the current wrapping all whitespace is preserved and apparent. But, if your boat is floated, then by all means go for it. -Bryce -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed patch - psql wraps at window width
OK, so COLUMNS should take precedence. I assume this is going to require us to read the COLUMNS enviroment variable in psql _before_ readline sets it, and that COLUMNS will only affect screen output, like ioctl(). Is that consistent? This whole thing is confusing enough at the point, I think a complete proposal needs to be articulated. It is hard to comment on a fragment of an idea. The main cases to cover are: (1) how to specify wrap for tty's (2) how to specify wrap for pipes (3) how to get wraped on platforms that don't have the ioctl (presumably windows without cygwin) (4) how to set up different defaults for tty's and pipes (e.g. wrap interactive tty's, but leave output aligned for scripts). And perhaps, as a bonus comment on (5) the idea of having psql NOT source .psqlrc I hope at some point someone will actually try the actual core wrapping code, and comment on it. -Bryce -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed patch - psql wraps at window width
Tom Lane wrote: This patch seems sufficiently controversial that commit now is the very last thing that should happen to it. I suggest committing the PrintTable stuff and not worrying about whether that breaks the wrap patch. regards, tom lane\ AFIK, the only thing that's controversial about the patch is how to turn it on and off -- the actual core code appears to be inflaming no passions. And it's the core code that presents merge issues. Could it be committed with a hidden enable syntax, for the interim? Or even no enable syntax, just to have it in the code base? \pset format wrap-beta-test on -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed patch - psql wraps at window width
Gregory Stark wrote: [No I wasn't thinking of that, that's an interesting case too though I think we might need to think a bit harder about cases that wrap poorly. If you have long column headings we could wrap those too. But what if you have enough space for just a few characters per column and you have long text fields in those columns?] I've been using this patch for months. After the first week, I switched to the behavior above (the wrap code gives up at a certain point). It is a lot better, try it for yourself. If you try to cram too much stuff onto a line it's going to become an even more unreadable mess of very very tall columns. Wrapping column headings only gets you so far, delaying the inevitable a little bit. A patch to squeeze out extra header space, or abbreviate headers would be an advance. -Bryce \pset format aligned autowrap \pset format aligned 80 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed patch - psql wraps at window width
Re: [HACKERS] Proposed patch - psql wraps at window width
Tom Lane wrote: Well, personally I haven't read the core code yet, since it's not commit fest yet ;-). I don't know whether there are any issues there, but it wouldn't surprise me given the number of issues in the control code. regards, tom lane I'm biased because I wrote the patch. However -- I think the core is commitable (it won't break anything else, or have complex dependencies or bloat). The issue of $COLUMNS was identified as unresolved at the time the patch was submitted, and I think it's the only bit in serious question. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Proposed patch - psql wraps at window width
Tom Lane wrote: Bruce Momjian [EMAIL PROTECTED] writes: I don't see that behavior here on Ubuntu 7.10: $ COLUMNNS=120 ls -C |cat archive cdinitrd lost+found proc srv usr basement.usr dev initrd.img media root sys var bin etc laptop mnt rtmp tmp vmlinuz boot home lib opt sbin uwin $ ls --version ls (GNU coreutils) 5.97 Well, it's *certainly* gonna ignore COLUMNNS. regards, tom lane I'm having trouble seeing the relevance, either way. First many shells don't set $COLUMNS at all (readline does it for psql). And most shells that set $COLUMNS don't export it. So most people get different output from: # ls -C # ls -C | cat Unless they are in the habit of doing: # COLUMNS=$COLUMNS ls -C |cat I think it's too weird to default pipes to whatever the terminal width happens to be. So that leaves you with an explicit command to set the width for pipes. -Bryce Echo $MANWIDTH -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Tech details - psql wraps at window width
Bruce Momjian wrote: Hey, I can work with this idea. First, there really is no 'off' mode for wrapped because that is aligned... Well, come to think of it, wrapped is not really a new output format in the sense of html or latex. It could build on aligned: \pset format aligned [autowrap|nowrap|nnn] But there's still the issue of wanting separate defaults for tty and stream outputs. The last thing you want is an admin deciding on wrapping, and then subtly breaking scripts. My personal desired defaults are: * Terminals autowrap. * Streams don't wrap, except in the rare case when I want to force a specific width (e.g. 79 for a newsgroup posting). -Bryce -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] Tech details - psql wraps at window width
As the originator of the psql wraps at window width patch, I'd like to set a matter or two straight: The ioctl() function does not fail under ssh, contrary to the assertion made several times. Nor does $COLUMNS remain static if the window size changes. $COLUMNS is not a property of a bash, you'll find it is set by the readline library. $COLUMNS is not fully cross-platform, though $MANWIDTH should be fine. Please supply counter examples if needed, but this is pretty well traveled ground. I think the original patch is fat and happy as far as interactive terminal use. But I agree it's not desirable to wrap file any sort of stream output, by default, as that would break just about any script known to mankind. Yet wrapping is a very user-friendly default for interactive terminals. This is potentially an irreconcilable inconsistency. I weigh in on the side of leaving it inconsistent, but making it really easy to force the behavior you want with something like: \pset format wrap [auto|nnn|off] But that leaves a big hole: what does the setting in .psqlrc refer to? Do we need separate controls in .psql? \pset format_terminal wrap [auto|nnn|off] \pset format_terminal html \pset format_stream wrap [auto|nnn|off] \pset format_stream html Where, on a stream, auto and off would have the same meaning, and \pset format would set both? -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] [PATCHES] Coding standards
Alvaro Herrera wrote: 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? The developer's FAQ is supposed to contain this kind of thing, but I think it's rather thin on actual details. (Some time ago it was proposed to create a style guide, but people here thought it was a waste of time and it will not cover what's really important, so we're stuck with repeating the advice over and over.) As a new patcher I'm certain to look at the top of the CVS tree. I'm not so certain to actually find and read a FAQ. But I've got the advice now, so I won't make the same missteps again -Bryce Nesbitt PS: less is more, keep any guide very very short -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Commit fest queue
Peter Eisentraut wrote: Am Dienstag, 15. April 2008 schrieb Zdenek Kotala: JavaDB and Firebird community use Jira Jira had already been rejected many years ago because it is not open source. Jira is also tremendously slow. Not a good system when an individual has to move quickly through a lot of reports. -Bryce -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
[HACKERS] [SQL] Proposed patch - psql wraps at window width
I've got a patch to psql that offers a no wider than terminal option, patched against cvs head. Would anyone be willing to test this before I submit the patch? # \pset format aligned-wrapped # \pset border 2 # select * from distributors order by did; Word wrap debug: rows=11 terminal=66 total_w=108 Max= 8 18 56 13 Avg= 2 11 17 0 +-+---+--+---+ | did | name|descr | long_col_name | +-+---+--+---+ | 5 | Food Heaven | default | | | 10 | Lah | default | | | 3 | Cat Food Heaven 3 | default | | | 4 | Cat Food Heaven 4 | default | | | 2 | Cat Food Heaven 2 | abcdefghijklmnopqrst : | | | | uvwxyz | | | 289 : short name| short| | | 287 : | | | | 32 | | | | | 99 | Tab \x09 tab | -- | | | 6 | multiwrap | line one : | | | | e| | | | | line two | | | | | line thr : | | | | : | | | | | | +-+---+--+---+ (9 rows) -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://mail.postgresql.org/mj/mj_wwwusr?domain=postgresql.orgextra=pgsql-hackers
