On Jun 22, 2006, at 9:39 PM, Tom Lane wrote:
Jim Nasby <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
