Group: pgsql.hackers


Subject: pg_dump and BINARY mode COPY
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/6/2007 12:43:50 PM
Simon Riggs <simon@2ndquadrant.com> writes: > Is there a reason why pg_dump avoids using BINARY mode COPY? To preserve platform and version independence of the dump. > Unless there is a specific reason not to we could/should allow an option > on the dump. Is there any evidence to show that there'd be enough benefit to warrant taking such a risk with your dumps? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

Subject: pg_dump and BINARY mode COPY
From: tgl@sss.pgh.pa.us (Tom Lane)
Date: 12/6/2007 1:22:19 PM
Simon Riggs <simon@2ndquadrant.com> writes: > On Thu, 2007-12-06 at 12:43 -0500, Tom Lane wrote: >> To preserve platform and version independence of the dump. > Only if there is a risk. Since a common route to upgrade is a > dump/restore back onto same box it seems worth having an option to do > this. I think you missed the point about version independence. That would be exactly the scenario where a version-to-version change in binary format --- for instance, "money" widening to 64 bits in 8.3 --- would burn you. Furthermore, this doesn't seem like a scenario where performance ought to be the primary concern. How often do you do major version upgrades? regards, tom lane ---------------------------(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