suggestion for improving TMPDIR and "--format" docs for pg_dump

Am Freitag, 9. M�rz 2007 03:30 schrieb Mark Stosberg:

The tar format needs some space to create temporary files. By default
"/tmp" is used. On systems with small "/tmp" partitions, set the
"TMPDIR" environment variable to a location with more space, such as
"/usr/tmp".

That is really standard operating system behavior. We don't need to duplicate
that information.

It woud also be nice to document that the full names "custom" and "tar" are
supported. Longer names can be nice for clarity.

They are. You must be looking at an older version.

( Unfortunately, wrong formats like "txx" also work instead of throwing
an error. )

Send a patch.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:

Am Freitag, 9. M�rz 2007 03:30 schrieb Mark Stosberg:

The tar format needs some space to create temporary files. By default
"/tmp" is used. On systems with small "/tmp" partitions, set the
"TMPDIR" environment variable to a location with more space, such as
"/usr/tmp".

That is really standard operating system behavior. We don't need to duplicate
that information.

So is

./configure
make
make install

These are all external, standard programs, but they are common and
useful to document with applications. I think a small amount of
redundancy is documentation is a good thing.

When I wanted to use a different tmp dir, I searched the PostgreSQL docs
for how to do that, because I was using a PostgreSQL tool. I had no why
of knowing whether PostgreSQL was even using standard conventions of
tmpdir handling, of if it did it's own thing. Also, after several years
of being professional involved with Unix system maintenance, I was not
aware that this was a standard feature. Surely then, less advanced users
would benefit from the documentation.

It woud also be nice to document that the full names "custom" and "tar" are
supported. Longer names can be nice for clarity.

They are. You must be looking at an older version.

You are correct. Sorry about that.

( Unfortunately, wrong formats like "txx" also work instead of throwing
an error. )

Send a patch.

I appreciate the sentiment, by my C skills are weak.

Mark

Mark Stosberg wrote:

It woud also be nice to document that the full names "custom" and "tar" are
supported. Longer names can be nice for clarity.

( Unfortunately, wrong formats like "txx" also work instead of throwing
an error. )

I don't see that with current CVS:

$ pg_dump --format=x test
pg_dump: invalid output format "x" specified

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Mark Stosberg wrote:

It woud also be nice to document that the full names "custom" and "tar" are
supported. Longer names can be nice for clarity.

( Unfortunately, wrong formats like "txx" also work instead of throwing
an error. )

I don't see that with current CVS:

$ pg_dump --format=x test
pg_dump: invalid output format "x" specified

Bruce,

I think the specific test case would have to start with a valid letter,
like "t", and then include invalid characters. Try this instead:

pg_dump --format=tx test

Mark

Mark Stosberg wrote:

Bruce Momjian wrote:

Mark Stosberg wrote:

It woud also be nice to document that the full names "custom" and "tar" are
supported. Longer names can be nice for clarity.

( Unfortunately, wrong formats like "txx" also work instead of throwing
an error. )

I don't see that with current CVS:

$ pg_dump --format=x test
pg_dump: invalid output format "x" specified

Bruce,

I think the specific test case would have to start with a valid letter,
like "t", and then include invalid characters. Try this instead:

pg_dump --format=tx test

Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
"append" and "file" too.

Patch attached and applied.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian <bruce@momjian.us> writes:

Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
"append" and "file" too.

Surely these should all be pg_strcasecmp?

regards, tom lane

Tom Lane wrote:

Bruce Momjian <bruce@momjian.us> writes:

Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
"append" and "file" too.

Surely these should all be pg_strcasecmp?

Yep, fixed.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
"append" and "file" too.

Append is undocumented as it's intended to be used by pg_dumpall, not
directly by users.

Regards, Dave.

Dave Page wrote:

Bruce Momjian wrote:

Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
"append" and "file" too.

Append is undocumented as it's intended to be used by pg_dumpall, not
directly by users.

Ah, OK, but there should be a clear comment somewhere about that. I
will add it.

--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Dave Page wrote:

Bruce Momjian wrote:

Thanks for the report. I have corrected this and the fix will be in
PostgreSQL 8.3. Interestingly, we support non-documented option
"append" and "file" too.

Append is undocumented as it's intended to be used by pg_dumpall, not
directly by users.

Ah, OK, but there should be a clear comment somewhere about that. I
will add it.

Thanks.

Regards Dave