> eh.. i could see some things, like tsearch2 or pg_autovacuum, which > afaik are almost if not completely compatible with 7.3, which will not > get back ported. Also fixes in some of the extra tools like psql could > be very doable, I know I had a custom psql for 7.2 that back patched the > \timing option and some of the pager fixes. now, weather that could be > done with stuff closer to core, i don't know...
Sure but businesses don't like to upgrade unless they have too. If we really want to attract more business to using PostgreSQL then they need to feel like they don't have to upgrade every 12 months. Upgrading is expensive and it rarely goes as smoothly as a dump/restore. > > Furthermore, adding more features to 7.3.x reduces the incentive to > > upgrade to 7.4, worsening the support problem: the more people using old > > releases, the more demand there will be for backported features, leading > > to more people using 7.3, leading to more demand for ... I am considering a time limited type thing. Not open ended. Something like 18 or 24 months (max) from release of the new version. You can't expect business to consider that timeframe during the development of the new release. They want to see the new release in action for a period of time. They also want time to play with the new release without sacrificing support for the previous release. > <homer>mmm. in place upgrade</homer> In reality in place upgrade will never work. Sure we can build a script that will deal with PostgreSQL itself, but not user defined data types, operators, functions etc... Those are all things that need stable time to migrate and test. Sincerely, Joshua Drake > > Robert Treat > -- Co-Founder Command Prompt, Inc. The wheel's spinning but the hamster's dead ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly