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
