Dave Page wrote:
>
>
>Been doing it that way since 6.3 (before pg_restore existed iirc). I
>keep doing it that way because there are no real space issues for me,
>and if I ever need to restore a system from backup, I can upgrade at the
>same time and still be able to massage the dump file into the new
>version of PostgreSQL if required. I think the easy answer is to just
>assume the file is a text dump if a signature cannot be found, and just
>pipe it to psql (so we don't have to worry about handling \connect or
>\copy ourselves).
>
>
I really want to leave this to experts, calling psql themselves.
Implementing plain restore suggests it as an equivalent alternative,
which it is not.
Backup/Restore tools are for easy and safe support of standard backup
situations, i.e. if I hit "backup" I assume the resulting file to
include anything I might need later. Additionally, a restore selection
should be available. We have this only with compressed and tar, not
plain. As you already mentioned, plain is for special purposes reworking
the output (do it on your own risk, if you know really what you do) or
for ancient backward compatibility.
>And some advantages.
>
>
To say it with different words:
pg_dump has two modes: one creating backup files (compressed/tar), the
other extraction of data for later manipulation. That's certainly not
paired with pg_restore. I'm beginning to think about splitting these two
tasks into two separate tools.
>I always assume the worst (as one should with backups IMO) - that
>something will go wrong and I may need to massage the data for some
>reason.
>
>
If you need to massage the file, you'll take an editor for that. I'd
recommend the Query Tool....
>The bottom line is, whatever view you take, plain text backups can be
>done and are done - thus we should try to support them.
>
>
I refuse to name that pg_dump plain thing a backup. It's a data
extraction, object to manipulation.
BTW, I'm waiting for PITR, which will offer the backup type that I
*really* want.
Regards,
Andreas
