Re: how robust are custom dumps?

On Wed, Apr 25, 2012 at 9:51 AM, Magnus Hagander <magnus(at)hagander(dot)net>wrote:

> We used to have a bug/lackoffeature in pg_dump at the 2GB boundary as
> well, IIRC, specifically on Win32. Maybe you were hit by that one..

Yes, possibly. I didn't even know how to make a compressed plain dump, but
that doesn't really plea my case :/

> > i do have one suggestion.
> > pg_restore only gives a user this feedback, when he makes this
> > mistake:"pg_restore: [archiver] input file does not appear to be a valid
> > archive".
> >
> > Would it be feasible for pg_restore to detect that it is a different
> pg_dump
> > format and inform the user about it?
>
>
The main one you'd want to detect is plain I think - and I don't know
> if we can reliably detect that. It could be just a generic textfile,
> after all - how would we know the difference?
>

Well, on linux you could make pg_dump run /usr/bin/file on the file to see
what kind it is. If it is gzipped, suggest that it might be a gzipped plain
dump, if it is plain text, suggest that it might be a plain dump (etc,
also bzip2). That's all.
You don't have to be sure that it is valid, just say a bit more than "does
not appear to be a valid archive". Help a user in a bad situation.

Only, i know that postgres runs on many platforms, so you probably can't
run /usr/bin/file on all of those (or might not be installed on linux
machine). So it probably should be part of pg_restore itself.

WBL
--
"Quality comes from focus and clarity of purpose" -- Mark Shuttleworth