Horton

Re: Non-text mode for pg_dumpall

Mahendra Singh Thalor <mahi6run@gmail.com>

View thread
From: Mahendra Singh Thalor <mahi6run@gmail.com>
To: Andrew Dunstan <andrew@dunslane.net>, tushar <tushar.ahuja@enterprisedb.com>
Cc: Noah Misch <noah@leadboat.com>, Tom Lane <tgl@sss.pgh.pa.us>, Álvaro Herrera <alvherre@alvh.no-ip.org>, jian he <jian.universality@gmail.com>, Srinath Reddy <srinath2133@gmail.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-10-28T06:02:24Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Add non-text output formats to pg_dumpall

  2. Improve pg_dump/pg_dumpall help synopses and terminology

  3. Non text modes for pg_dumpall, correspondingly change pg_restore

  4. Doc: manually break lines in wide UUID examples.

Attachments

On Thu, 16 Oct 2025 at 16:24, Mahendra Singh Thalor <mahi6run@gmail.com> wrote:
>
> On Wed, 15 Oct 2025 at 23:05, Mahendra Singh Thalor <mahi6run@gmail.com> wrote:
> >
> > On Sun, 24 Aug 2025 at 22:12, Andrew Dunstan <andrew@dunslane.net> wrote:
> > >
> > >
> > > On 2025-08-23 Sa 9:08 PM, Noah Misch wrote:
> > >
> > > On Wed, Jul 30, 2025 at 02:51:59PM -0400, Andrew Dunstan wrote:
> > >
> > > OK, now that's reverted we should discuss how to proceed. I had two thoughts
> > > - we could use invent a JSON format for the globals, or we could just use
> > > the existing archive format. I think the archive format is pretty flexible,
> > > and should be able to accommodate this. The downside is it's not humanly
> > > readable. The upside is that we don't need to do anything special either to
> > > write it or parse it.
> > >
> > > I would first try to use the existing archiver API, because that makes it
> > > harder to miss bugs.  Any tension between that API and pg_dumpall is likely to
> > > have corresponding tension on the pg_restore side.  Resolving that tension
> > > will reveal much of the project's scope that remained hidden during the v18
> > > attempt.  Perhaps more important than that, using the archiver API means
> > > future pg_dump and pg_restore options are more likely to cooperate properly
> > > with $SUBJECT.  In other words, I want it to be hard to add pg_dump/pg_restore
> > > features that malfunction only for $SUBJECT archives.  The strength of the
> > > archiver architecture shows in how rarely new features need format-specific
> > > logic and how rarely format-specific bugs get reported.  We've had little or
> > > no trouble with e.g. bugs that appear in -Fd but not in -Fc.
> > >
> > >
> > > Yeah, that's what we're going to try.
> > >
> > >
> > > cheers
> > >
> > >
> > > andrew
> > >
> > > --
> > > Andrew Dunstan
> > > EDB: https://www.enterprisedb.com
> >
> > Thanks Andrew, Noah and all others for feedback.
> >
> > Based on the above suggestions and discussions, I removed sql commands
> > from the global.dat file. For global commands, now we are making
> > toc.dat/toc.dmp/toc.tar file based on format specified and based on
> > format specified, we are making archive entries for these global
> > commands. By this approach, we removed the hard-coded parsing part of
> > the global.dat file and we are able to skip DROP DATABASE with the
> > globals-only option.
> >
> > Here, I am attaching a patch for review, testing and feedback. This is
> > a WIP patch. I will do some more code cleanup and will add some more
> > comments also. Please review this and let me know design level
> > feedback. Thanks Tushar Ahuja for some internal testing and feedback.
> >
>
> Hi,
> Here, I am attaching an updated patch. In offline discussion, Andrew
> reported some test-case failures(Thanks Andrew). I fixed those.
> Please let me know feedback for the patch.
>

Hi,
Here I am attaching a re-based patch as v02 was failing on head.
Thanks Tushar for the testing.
Please review this and let me know feedback.

-- 
Thanks and Regards
Mahendra Singh Thalor
EnterpriseDB: http://www.enterprisedb.com