Re: Pains in upgrading to 8.3 - Mailing list pgsql-general

From Tony Caduto
Subject Re: Pains in upgrading to 8.3
Date
Msg-id 47B5BC12.7070505@amsoftwaredesign.com
Whole thread Raw
In response to Re: Pains in upgrading to 8.3  (paul rivers <rivers.paul@gmail.com>)
Responses Re: Pains in upgrading to 8.3
Re: Pains in upgrading to 8.3
Re: Pains in upgrading to 8.3
List pgsql-general
paul rivers wrote:
>>
> Going from 8.2.4 and 8.2.6 to 8.3.0 has been painless for me.
> However, unlike the blogger you cite, I read the directions before,
> not after, attempting it.


The blogger has a point about pg_dump and restore, it could be much
better, for example
the backup process could be part of the server core and instead of
having a fat client where most of the process is running on the client,
a API could be
used where the backup is generated on the server and then have options
where it could be left on the server or transferred to the clients PC.

Using pg_dump remotely is becoming a pain because it's not really
backwards compatible with earlier releases, so you end up having to have
multiple copies laying around to use on different server versions.

While Firebird is mostly inferior, it's backup system is much nicer that
PostgreSQL's system.  Firebird uses a backup API, so if you backup
remotely there is no fat client needed and it eliminates all the
dependency issues on the client side.  The client access library
implements the API and that's it.
You of course could hack something similar on PGSQL by using SSH and
remotely executing pg_dump on the server, but that does not really help
on windows servers where SSH is not a common thing.

The backup data is coming back to the client regardless, so why not just
return it as a result set?

Just my opinion on the matter, no flames please.


Thanks,

Tony



pgsql-general by date:

Previous
From: Erik Jones
Date:
Subject: Re: dynamic crosstab
Next
From: paul rivers
Date:
Subject: Re: Pains in upgrading to 8.3