eters...
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: r
erged 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 p
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/
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
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
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 mor
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 an
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 wo
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 d
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
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 thin
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
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
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
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
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|
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,
he 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
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 th
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 tota
21 matches
Mail list logo
