Обсуждение: pg_dump versioning
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? ISTM it would make it much more feasible to handle changes to how things work automatically. -- 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
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? ISTM it would make it much more feasible > to handle changes to how things work automatically. Yes, we have talked about that, and it would work for pg_dump-generated dumps. What it might not work for cleanly are dumps moved a different way, or application changes, so while it might help in some cases, being able to get things working without the version info is desirable. If we ever get to a case where we _need_ to use it, it would be good to have, just in case. -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 359-1001+ If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania19073
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. 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. regards, tom lane
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