pg_dump and BINARY mode COPY
Is there a reason why pg_dump avoids using BINARY mode COPY?
(Or am I missing something?)
Unless there is a specific reason not to we could/should allow an option
on the dump.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
On Thu, Dec 06, 2007 at 05:30:02PM +0000, Simon Riggs wrote:
Is there a reason why pg_dump avoids using BINARY mode COPY?
(Or am I missing something?)Unless there is a specific reason not to we could/should allow an option
on the dump.
Probably because BINARY dumps arn't portable. Just guessing...
Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
Show quoted text
Those who make peaceful revolution impossible will make violent revolution inevitable.
-- John F Kennedy
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
On Thu, 2007-12-06 at 12:43 -0500, Tom Lane wrote:
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.
OK, thats what I guessed.
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?
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.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
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
On Thu, 2007-12-06 at 13:22 -0500, Tom Lane wrote:
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.
OK
Furthermore, this doesn't seem like a scenario where performance ought
to be the primary concern. How often do you do major version upgrades?
Not often enough.
If it was faster, we would rely on more people actually doing it.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
I use often pgdump... and we have many bytea on our database...
Without binary COPY, backup is very slow and takes 4x more space on the
network wire...
It would be great to have an option (--binary) with eventually a WARNING
message (that your backup could be not portable across architecture...)
but i think that 99% of the time we don't change between x86 or ppc....
please think for users...
Hubert
Le jeudi 06 décembre 2007 à 18:32 +0000, Simon Riggs a écrit :
On Thu, 2007-12-06 at 13:22 -0500, Tom Lane wrote:
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.OK
Furthermore, this doesn't seem like a scenario where performance ought
to be the primary concern. How often do you do major version upgrades?Not often enough.
If it was faster, we would rely on more people actually doing it.
_________________________________________________
Ce message et les éventuels documents joints peuvent contenir des informations confidentielles.
Au cas où il ne vous serait pas destiné, nous vous remercions de bien vouloir le supprimer et en aviser immédiatement l'expéditeur. Toute utilisation de ce message non conforme à sa destination, toute diffusion ou publication, totale ou partielle et quel qu'en soit le moyen est formellement interdite.
Les communications sur internet n'étant pas sécurisées, l'intégrité de ce message n'est pas assurée et la société émettrice ne peut être tenue pour responsable de son contenu.