Re: Pains in upgrading to 8.3

Поиск
Список
Период
Сортировка
От Tony Caduto
Тема Re: Pains in upgrading to 8.3
Дата
Msg-id 47B5BC12.7070505@amsoftwaredesign.com
обсуждение исходный текст
Ответ на Re: Pains in upgrading to 8.3  (paul rivers <rivers.paul@gmail.com>)
Ответы Re: Pains in upgrading to 8.3
Re: Pains in upgrading to 8.3
Re: Pains in upgrading to 8.3
Список 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 по дате отправления:

Предыдущее
От: Erik Jones
Дата:
Сообщение: Re: dynamic crosstab
Следующее
От: paul rivers
Дата:
Сообщение: Re: Pains in upgrading to 8.3