Re: why -Fdance archive format option works with ./pg_restore but not with ./pg_dump?
Srinath Reddy Sadipiralla <srinath2133@gmail.com>
From: Srinath Reddy <srinath2133@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@lists.postgresql.org
Date: 2025-01-25T12:42:44Z
Lists: pgsql-hackers
Attachments
- 0001-Parse-the-format-option-for-pg_restore-with-pg_strcasecmp.patch (application/octet-stream) patch 0001
On Fri, Jan 24, 2025 at 8:54 PM Tom Lane <tgl@sss.pgh.pa.us> 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. > > regards, tom lane > Agreed and made the patch as suggested . Regards, Srinath Reddy Sadipiralla, EDB:http://www.enterprisedb.com
Commits
-
Tighten pg_restore's recognition of its -F (format) option values.
- 04ace176e08f 18.0 landed