Horton

Re: Non-text mode for pg_dumpall

Andrew Dunstan <andrew@dunslane.net>

View thread
From: Andrew Dunstan <andrew@dunslane.net>
To: Noah Misch <noah@leadboat.com>
Cc: 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-25T19:31:47Z
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 2025-07-25 Fr 12:21 PM, Noah Misch wrote:
> On Thu, Jul 24, 2025 at 04:33:15PM -0400, Andrew Dunstan wrote:
>> On 2025-07-21 Mo 8:53 PM, Noah Misch wrote:
>>> I suspect this is going to end with a structured dump like we use on the
>>> pg_dump (per-database) side.  It's not an accident that v17 pg_restore doesn't
>>> lex text files to do its job.  pg_dumpall deals with a more-limited set of
>>> statements than pg_dump deals with, but they're not _that much_ more limited.
>>> I won't veto a lexing-based approach if it gets the behaviors right, but I
>>> don't have high hopes for it getting the behaviors right and staying that way.
>> I have been talking offline with Mahendra about this. I agree that we would
>> be better off with a structured object for globals. But the thing that's
>> been striking me all afternoon as I have pondered it is that we should not
>> be designing such an animal at this stage of the cycle. Whatever we do we're
>> going to be stuck supporting, so I have very reluctantly come to the
>> conclusion that it would probably be better to back the feature out and have
>> another go for PG 19.
> That makes sense to me.  It would be quite a sprint to get this done in time,
> and that wouldn't leave much room for additional testing and feedback before
> the final release.  I agree with the reluctance and with the conclusion.



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.

cheers

andrew

--
Andrew Dunstan
EDB:https://www.enterprisedb.com