Re: Dump size bigger than pgdata size?
От | Jim Nasby |
---|---|
Тема | Re: Dump size bigger than pgdata size? |
Дата | |
Msg-id | 219F801D-2039-4729-8CEC-B9EEC0C2F3BF@pervasive.com обсуждение исходный текст |
Ответ на | Re: Dump size bigger than pgdata size? (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-admin |
On Jun 22, 2006, at 9:39 PM, Tom Lane wrote: > Jim Nasby <jnasby@pervasive.com> writes: >> On Jun 21, 2006, at 12:00 PM, Tom Lane wrote: >>> This could be avoided by using COPY BINARY format, but I don't >>> see any >>> very nice way to do that in the context of pg_dump --- it needs to >>> intermix COPY data with SQL commands ... > >> Would the tar or custom format allow for this? IIRC, at least tar >> puts all the copied data into separate files... > > Well, you could sorta do that, but the case that would stop working is > pg_restore output to a plain text SQL script (and related issues > such as > the ability to use the feature in the context of pg_dumpall). Having > just gotten done fixing similar inconsistencies in pg_dump/pg_restore > for BLOBs, I'm not eager to re-introduce 'em for COPY BINARY ... Yeah, but how many people actually do that anyway? I can't really come up with a use-case for it, and I'm pretty sure there's other gains to be had by turning custom or tar format into more of a 'binary dump'. For one thing, that should ease the need to run the newer version of pg_dump when upgrading (if we put the requisite brains into pg_restore). I suppose we could put support in pg_restore to convert between BINARY and escaped as needed; or just disallow pg_restore from dumping SQL if there's binary data (maybe have it include copy statements that reference the specific files). -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
В списке pgsql-admin по дате отправления: