Re: pg_dump versioning

On Mon, Oct 03, 2005 at 12:11:49AM -0400, Tom Lane wrote:
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461