Re: pg_dump versioning

Поиск
Список
Период
Сортировка
От Jim C. Nasby
Тема Re: pg_dump versioning
Дата
Msg-id 20051004145903.GJ40138@pervasive.com
обсуждение исходный текст
Ответ на Re: pg_dump versioning  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Oct 03, 2005 at 12:11:49AM -0400, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Jim C. Nasby wrote:
> >> Watching the discussion about how to handle nextval() and keep it dump
> >> compatible makes me wonder: would it be useful to encode database or
> >> dump version info into dumps?
> 
> > If we ever get to a case where we _need_ to use it, it would be good to
> > have, just in case.
> 
> The trouble is that it won't help you until years after you invest
> the work --- invariably, the version info you wish you had is for
> distinguishing between different *old* releases.

True, but that will always be the case until someone adds it. And in
this particular case, ISTM it shouldn't require much effort to add the
info. Plus, it would certainly be useful for users to be able to examine
a dump and find out what exact version of the database/pgdump was used
to produce it. This would also allow for pg_restore or even a dump piped
into psql to throw a warning or error if being fed a dump version it
might not be able to handle (ie: feeding a newer dump to and older
version).

> I'm not real excited about it myself.  My own design experience says
> that version numbers aren't that hot as a way of determining "does this
> data have the X nature?".  If you can't test for the problem directly,
> you haven't thought hard enough.

True, but at least if the info is made available now it could be used
down the road if needed.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [PERFORM] A Better External Sort?
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: [PERFORM] A Better External Sort?