Re: Deprecating, and scheduling removal of, pg_dump's tar format. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Deprecating, and scheduling removal of, pg_dump's tar format.
Date
Msg-id 31452.1532715126@sss.pgh.pa.us
Whole thread Raw
In response to Re: Deprecating, and scheduling removal of, pg_dump's tar format.  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-hackers
Jeff Janes <jeff.janes@gmail.com> writes:
> But he isn't proposing getting rid of -Fp, just -Ft.  Isn't -Ft is just as
> PostgresSQL-specific
> as -Fd is?

No.  The point about -Ft format is that you can extract files that contain
SQL text and COPY data, using nothing but standard Unix tools (i.e. tar).
So just as with a plain-text dump, you'd have some work to do to get your
data into some other RDBMS, but it'd be mostly about SQL-compatibility
problems, not "what the heck is this binary file format".

I was thinking before that -Fd had basically the same payload files as
an -Ft archive, but it doesn't: we don't emit anything corresponding to
the "restore.sql" member of an -Ft archive.  This means that -Fd still
leaves you needing PG-specific tools to interpret the toc.dat file,
so it's not a plausible answer if you would like to have something that's
more structured than a plain-text dump but will still be of use if your
PG tools are not available.

The -Ft format certainly has got its problems, and I wouldn't complain
if we decided to, say, extend -Fd format so that you could also get
info out of it without using pg_restore.  But I do not think we should
just drop -Ft as long as it's our only nonproprietary structured
dump format.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Chris Travers
Date:
Subject: Re: How can we submit code patches that implement our (pending) patents?
Next
From: Andrew Gierth
Date:
Subject: Re: Deprecating, and scheduling removal of, pg_dump's tar format.