Re: Non-text mode for pg_dumpall
От | Andrew Dunstan |
---|---|
Тема | Re: Non-text mode for pg_dumpall |
Дата | |
Msg-id | 82eb35b8-7f07-493b-b689-0934919e1dc3@dunslane.net обсуждение исходный текст |
Ответ на | Re: Non-text mode for pg_dumpall (Noah Misch <noah@leadboat.com>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: