Jim C. Nasby wrote:
On Thu, Jan 26, 2006 at 11:36:15AM +0100, Peter Eisentraut wrote:
James William Pye wrote:
Why should initdb give it [processing
information] to the user if the user didn't request it in the first
place?
Because it shows important information that we want
unsubscribe
David Fetter [EMAIL PROTECTED] writes:
On Thu, Jan 26, 2006 at 10:17:05PM -0500, Tom Lane wrote:
Seems to me that psql -c 'COPY ...' is a more likely front-end for
such a process.
Actually, it's not. I'm attaching my preliminary patch, as I see I
haven't explained it well enough.
The patch
Matthew T. O'Connor matthew@zeut.net writes:
Also, somebody made a real good point about rolled-back insertions.
Even if the only command you ever apply to the table is INSERT, you
could still have dead rows in the table if some of those transactions
occasionally roll back.
hmm... That's
Thomas Hallgren [EMAIL PROTECTED] writes:
This is how I perceive the output from initdb:
- The output lists settings for locale, encoding and buffer usage. Why
are these specific settings be of special interest? Anyone with an
interest in them knows where to find them anyway. This
Those who don't use it will never see it.
It does however add more maintenance to the code.
Furthermore, it's quite unclear why you'd use pg_dump at all to
generate a data file that you intend to feed to some other program.
In my case, it's about being copy/paste friendly.
Tom Lane wrote:
I get a WARNING: enabling trust authentication for local connections.
Now this information *is* important. Unfortunately it's mixed in with
all the rest unless I use a special redirect of stdout.
To apply your own argument, why is that important? Anyone with an
Tom Lane wrote:
I think this is the fault of the stats system design. AFAICT from a
quick look at the code, inserted/updated/deleted tuples are reported
to the collector in the same way regardless of whether the sending
transaction committed or rolled back. I think this is unquestionably
a
Alvaro Herrera [EMAIL PROTECTED] writes:
This warning was added because of security considerations AFAIR. If the
intent is to make initdb super-quiet, we still have to have security in
mind. So if you want it to not say anything by default, instead of
throwing a warning it should throw an
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
This warning was added because of security considerations AFAIR. If the
intent is to make initdb super-quiet, we still have to have security in
mind. So if you want it to not say anything by default, instead of
throwing a warning
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think this is unquestionably
a bug, at least for autovacuum's purposes --- though it might be OK
for the original intent of the stats system, which was simply to track
activity levels.
Any thoughts about how it ought to work?
I
I wrote:
While we can probably all agree that it's not very interesting to
mention every single directory that initdb creates, I find it ...
I took a quick look at the source and see that it would be trivial
to reduce the current output from
creating directory /home/postgres/v82/data ... ok
Has there been any movement on this? as of 8.1.2 psql still whines on
OS X tiger when you exit.
I realize it is not significant, but I'd still rather not see it.
In the interim, I've done:
errno = 0;
write_history(fname); /* return value is not standardized */
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
I think this is unquestionably
a bug, at least for autovacuum's purposes --- though it might be OK
for the original intent of the stats system, which was simply to track
activity levels.
Any thoughts about how
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
My question was at a higher level, actually: *what* should we be
counting?
Oh, I see. Do you think small incremental improvements to the stat
system will buy us much? I think we should be thinking big here, i.e.
rewrite most stuff
Tom Lane wrote:
Alvaro Herrera [EMAIL PROTECTED] writes:
Tom Lane wrote:
My question was at a higher level, actually: *what* should we be
counting?
Oh, I see. Do you think small incremental improvements to the stat
system will buy us much? I think we should be thinking big here,
to
creating directory /home/postgres/v82/data ... ok
creating subdirectories ... ok
selecting default max_connections ... 100
...
Less is more :)
I like it.
Joshua D. Drake
regards, tom lane
---(end of
Joshua D. Drake [EMAIL PROTECTED] writes:
David I don't get this... what are you copying from/to that would
wouldn't just script? If you throw into a script you can change
the delimiter on the fly using translation.
I think what he's getting at is for things like, say, a contrib package with
On Fri, 2006-01-27 at 13:12 -0500, Greg Stark wrote:
Personally I find anything that would encourage people to use anything other
than tabs evil anyways. All those people who think | is somehow a reasonable
choice or want to use commas and then get all confused trying to escape them
and
Andrew Dunstan [EMAIL PROTECTED] writes:
I could not disagree more. The invisibility of tabs makes their use as a
delimiter wholly evil. I have lost count of the number of corrupted
makefiles etc. I have seen because a tab got converted to a space and it
was impossible to tell.
More tears
On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
I could not disagree more. The invisibility of tabs makes their use as a
delimiter wholly evil. I have lost count of the number of corrupted
makefiles etc. I have seen because a tab got converted to
Andrew Dunstan [EMAIL PROTECTED] writes:
On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
That line of argument leads to the suggestion that pg_dump should just
use something else (I'd vote for |), all the time, in order to produce
more robust dump files. I still don't see the argument for
On Jan 27, 2006, at 10:21 AM, Jason Essington wrote:
Has there been any movement on this? as of 8.1.2 psql still whines
on OS X tiger when you exit.
I realize it is not significant, but I'd still rather not see it.
In the interim, I've done:
errno = 0;
Tom Lane [EMAIL PROTECTED] writes:
Andrew Dunstan [EMAIL PROTECTED] writes:
On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
That line of argument leads to the suggestion that pg_dump should just
use something else (I'd vote for |), all the time, in order to produce
more robust dump
On Fri, 2006-01-27 at 14:08 -0500, Tom Lane wrote:
Andrew Dunstan [EMAIL PROTECTED] writes:
On Fri, 2006-01-27 at 13:43 -0500, Tom Lane wrote:
That line of argument leads to the suggestion that pg_dump should just
use something else (I'd vote for |), all the time, in order to produce
more
Tom Lane wrote:
hmm... That's true. I don't think autovacuum doesn't anything to account
for the concept of rolledback inserts.
I think this is the fault of the stats system design. AFAICT from a
quick look at the code, inserted/updated/deleted tuples are reported
to the collector in
26 matches
Mail list logo
