Horton

Re: Non-text mode for pg_dumpall

Noah Misch <noah@leadboat.com>

View thread
From: Noah Misch <noah@leadboat.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Andrew Dunstan <andrew@dunslane.net>, Mahendra Singh Thalor <mahi6run@gmail.com>, Á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-07-27T23:56:28Z
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.

On Fri, Jul 25, 2025 at 04:59:29PM -0400, Tom Lane wrote:
> Andrew Dunstan <andrew@dunslane.net> writes:
> > Before we throw the baby out with the bathwater, how about this 
> > suggestion? pg_dumpall would continue to produce globals.dat, but it 
> > wouldn't be processed by pg_restore, which would only restore the 
> > individual databases. Or else we just don't produce globals.dat at all. 
> > Then we could introduce a structured object that pg_restore could safely 
> > use for release 19, and I think we'd still have something useful for 
> > release 18.
> 
> I dunno ... that seems like a pretty weird behavior.  People would
> have to do a separate text-mode "pg_dumpall -g" and remember to
> restore that too.  Admittedly, this could be more convenient than
> "pg_dumpall -g" plus separately pg_dump'ing each database, which is
> what people have to do today if they want anything smarter than a flat
> text dumpfile.  But it still seems like a hack --- and it would not be
> compatible with v19, where presumably "pg_dumpall | pg_restore"
> *would* restore globals.  I think that the prospect of changing
> dump/restore scripts and then having to change them again in v19
> isn't too appetizing.

+1