As I understand it, changes that require the dump restore fall into two categories, catalog changes, and on disk format changes. If that's the case (I'm as likely wrong as right here, I know) then it could be that most upgrades (say 7.4 to 7.5) could be accomplished more easier than the occasional ones that require actual disk format changes (i.e. 7.5 to 8.0)
If that's the case, I'd imagine that as postgresql gets more mature, on disk upgrades should become easier to implement, and dump/restore would only be required for major version upgrades at some point. Is that about right, and if so, would it make maintaining this kind of program simpler if it only had to handle catalog changes? On Tue, 16 Sep 2003, Andrew Rawnsley wrote: > > Let me run some numbers. I'm interested in the idea, and I think I can > push one of my clients on it. > > Do the core folk (Tom/Bruce/Jan/etc) think this is doable with that > sort of time commitment? Is it maintainable over time? Or are we > pissing in the wind? > > On Tuesday, September 16, 2003, at 03:59 PM, Joshua D. Drake wrote: > > > > >> > >> And that has nothing to do with user need as a whole, since the care > >> level I mentioned is predicated by the developer interest level. > >> While I know, Marc, how the whole project got started (I have read > >> the first posts), and I appreciate that you, Bruce, Thomas, and Vadim > >> started the original core team because you were and are users of > >> PostgreSQL, I sincerely believe that in this instance you are out of > >> touch with this need of many of today's userbase. And I say that with > >> full knowledge of PostgreSQL Inc.'s support role. If given the > >> choice between upgrading capability, PITR, and Win32 support, my vote > >> would go to upgrading. Then migrating to PITR won't be a PITN. > > > > If someone is willing to pony up 2000.00 per month for a period of at > > least 6 months, I will dedicated one of my programmers to the task. So > > if you want it bad enough there it is. I will donate all changes, > > patches etc.. to the project and I will cover the additional costs > > that are over and above the 12,000. If we get it done quicker, all the > > better. > > > > Sincerely, > > > > Joshua Drake > > > > -- > > Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC > > Postgresql support, programming shared hosting and dedicated hosting. > > +1-503-222-2783 - [EMAIL PROTECTED] - http://www.commandprompt.com > > The most reliable support for the most reliable Open Source database. > > > > > > > > ---------------------------(end of > > broadcast)--------------------------- > > TIP 8: explain analyze is your friend > > > -------------------- > > Andrew Rawnsley > President > The Ravensfield Digital Resource Group, Ltd. > (740) 587-0114 > www.ravensfield.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) > ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
