I humbly request on behalf of those who manage production postgresql instances that we change the default backup file format from -Fp to -Fc.
-1 in the case that output goes to stdout. It might make sense for when -f is specified. As a DBA, 90% of my usage of pg_dump was piped to psql, with the rest split between data-only dumps for individual tables and schema-only dumps. I think I used -Fc about twice -- before I figured out how to do PITR-style backups.
PITR is wonderful, I use it all the time. It has exactly zero to do with what we are talking about. We are talking about pg_dump and its usefulness. Are you suggesting that we tell people to not use pg_dump and instead use PITR?
That depends on what they are using it for. If they are using pg_dump to do backups that are better done with PITR, then they should use PITR. When I use pg_dump, it is because I want to see what it is that is getting dumped--if I didn't want it be human readable, I'd use a binary backup instead of a binary dump.
One of the things that first attracted me to PostgreSQL was that you use the tool provided to dump the data, and what you get by default is identifiably your data, rather than something that looks like it was designed to lock you in to some proprietary tool and never let you out again.
(Another thing that attracted me to it was that it didn't run around renaming things between every release.)
This, for example, is a valid and useful construct:
pg_dump test | psql test2
... or:
pg_dump -s test | psql test3
pg_dump -s test -fp| psql test3
A lot of scripts will be broken by changing the default format for piped output.
For the sake of sanity... really? You just proved my point. This isn't about developers. Developers now how to code. They can change a simple script. This is about production DBA/admins, the 98% of people using postgresql.
I don't think that adding a command line option constitutes coding. If they can't figure out how to do that for pg_dump, how are they ever going to use pg_restore in the first place?
