MIME-Version: 1.0
References: <CANzqJaAHOSNiOhe4D2hOBB46=puWQOZb=s=VQdNmUSOtOmRG5A@mail.gmail.com>
 <25e9749c-ff38-4832-9b26-386cac33b3d8@aklaver.com> <CANzqJaCMR-5eLMYy0ukywWeKpwySCAMQRrgKmW7A2CZ-mr9+0Q@mail.gmail.com>
 <7005ac8c-2f83-4122-9172-04bca268f987@aklaver.com> <CANzqJaBiUpeFExzS-wi8KzmZcxEEmi1FUVkoyL5=8FEx13S5dg@mail.gmail.com>
 <f3d35e91-9b80-4985-a1ca-fa0a5d8639d2@aklaver.com> <CAHAc2jcACDXv8=5EVO0YVVjANP=oj_=eeYeLXiG3LQC+kU0ewA@mail.gmail.com>
 <4b28e899-d802-43ce-b20b-655a9077f08f@gmail.com> <CANzqJaB86-8qozgb5Fmd48PJa4CrVo3o8BFGAiG0w6ynJfJJpA@mail.gmail.com>
 <CAFVAjJH3bA-rZNEyjDctD0TOZMjcyVqA7Ac_-xkBDaM8UUPFkA@mail.gmail.com>
In-Reply-To: <CAFVAjJH3bA-rZNEyjDctD0TOZMjcyVqA7Ac_-xkBDaM8UUPFkA@mail.gmail.com>
From: Shaheed Haque <shaheedhaque@gmail.com>
Date: Tue, 4 Jun 2024 22:35:21 +0100
Message-ID: <CAHAc2jeAiUzTv=MFY3EGgWF5LPJ6k-nOa0-_xekyDamnLehFNg@mail.gmail.com>
Subject: Re: Purpose of pg_dump tar archive format?
To: Gavin Roy <gavinr@aweber.com>
Cc: Ron Johnson <ronljohnsonjr@gmail.com>, 
	"pgsql-generallists.postgresql.org" <pgsql-general@lists.postgresql.org>
Content-Type: multipart/alternative; boundary="000000000000c627cd061a173ad5"
Archived-At: <https://www.postgresql.org/message-id/CAHAc2jeAiUzTv%3DMFY3EGgWF5LPJ6k-nOa0-_xekyDamnLehFNg%40mail.gmail.com>
Precedence: bulk

--000000000000c627cd061a173ad5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Tue, 4 Jun 2024 at 20:47, Gavin Roy <gavinr@aweber.com> wrote:

>
> On Tue, Jun 4, 2024 at 3:15=E2=80=AFPM Ron Johnson <ronljohnsonjr@gmail.c=
om>
> wrote:
>
>>
>> But why tar instead of custom? That was part of my original question.
>>
>
> I've found it pretty useful for programmatically accessing data in a dump
> for large databases outside of the normal pg_dump/pg_restore workflow. Yo=
u
> don't have to seek through one large binary file to get to the data secti=
on
> to get at the data.
>

This is true for us too; specifically, tar, including with compression, is
very convenient for both CLI and Python ecosystems.

--000000000000c627cd061a173ad5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, 4 Jun 2024 at 20:47, Gavin Ro=
y &lt;<a href=3D"mailto:gavinr@aweber.com">gavinr@aweber.com</a>&gt; wrote:=
<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8=
ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr=
"><div dir=3D"ltr"></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Tue, Jun 4, 2024 at 3:15=E2=80=AFPM Ron Johnson &lt;<=
a href=3D"mailto:ronljohnsonjr@gmail.com" target=3D"_blank">ronljohnsonjr@g=
mail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D=
"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-le=
ft:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><br></div><div class=3D"gmail_quo=
te"><div>But why tar instead of custom? That was part of my original questi=
on.</div></div></div></blockquote></div><div><br></div>I&#39;ve found it pr=
etty useful for programmatically accessing data in a dump for large databas=
es outside of the normal pg_dump/pg_restore workflow. You don&#39;t have to=
 seek through one large binary file to get to the data section to get at th=
e data.<br></div></blockquote><div><br></div><div>This is true for us too; =
specifically, tar, including with compression, is very convenient for both =
CLI and Python ecosystems. <br></div></div></div>

--000000000000c627cd061a173ad5--