Re: Non-text mode for pg_dumpall

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