Re: why -Fdance archive format option works with ./pg_restore but not with ./pg_dump?
От | Andrew Dunstan |
---|---|
Тема | Re: why -Fdance archive format option works with ./pg_restore but not with ./pg_dump? |
Дата | |
Msg-id | d5248404-5054-496b-8f30-7a7b51d54d29@dunslane.net обсуждение исходный текст |
Ответ на | Re: why -Fdance archive format option works with ./pg_restore but not with ./pg_dump? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On 2025-01-24 Fr 10:24 AM, Tom Lane wrote: > Andrew Dunstan <andrew@dunslane.net> writes: >> I don't think we need a new file for this. pg_backup_utils.c is already >> there for routines common to pg_restore and pg_dump. > I'm not even on board with having a new function, because I doubt > we should try to share this code in the first place. Who's to > say that pg_dump and pg_restore must support exactly the same list > of formats? For example, in the future we might decide that some > format is obsolete and desupport it in pg_dump, while continuing > to allow it for awhile in pg_restore for compatibility reasons. > A closer-to-home possibility is that the work to allow non-text > output from pg_dumpall will result in a format that pg_restore > can read but pg_dump (by itself) doesn't write. > > So I'd just scrap pg_restore's parsing logic for this and replace it > in-place. To the extent that that's copying and pasting stuff, fine. > It's not like there's no other duplicativeness in their switch-parsing > logic. > > Fair point. Agreed. cheers andrew -- Andrew Dunstan EDB: https://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: