Dave Page wrote:
On Fri, Feb 15, 2008 at 4:21 PM, Tony Caduto
<tony_caduto@xxxxxxxxxxxxxxxxxxxx> wrote:
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.
Not really an option - the reason it's recommended to use the new
pg_dump version with the older server when upgrading is to allow the
dump to be made in the way most compatible with the new server,
effectively doing some of the upgrade process as part of the dump
operation.
For the case of upgrading, it wouldn't work. But there are certainly
other cases where it would help. Say from your central pgadmin console
administering 10 servers from 3 different major release trees :-(
It can be done with commandline pg_dump, but it means you have to have
three different installs on your management or backup or whatever
machine. Those cases would certainly be easier if you could just call a
backup API on the server that would feed you the data... (yes, there are
ways to do it with ssh tunneling and whatever, but that's yet another
external service that has to be set up and configured)
I'm not saying it's worth the work and potential downsides, just that
there are clear upsides :-)
//Magnus
---------------------------(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
