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.
I have made the following experience:
If a new application is deployed and if it stays unchanged 99% of all bugs in the database or the software itself will be found within a comparatively short amount of time.
If a business partner decides to continue to work on his application (which means changing it) he will accept new PostgreSQL releases.
Up to now upgrading PostgreSQL has never been a problem because have expected major releases to be stable. In addition to that dump/restore worked nicely.
I remember having slightly more work when we switched to 7.3 because somehow type casts are handled differently (less implicit casts - I think that was the problem) but for that purpose intelligent customers have testing environments so that nothing evil can happen on the production system.
I don't think back porting features is a good idea. As Marc said: PostgreSQL is the kernel and not an ordinary package.
Personally I think that a database product should always be a rock solid product. Unless applications such as, let's say, xclock, database are truly critical and customers won't forget about releases eating data. However, in my opinion they can understand that maintenance is necessary.
When you deal with the systems I do, the cost to a customer to migrate to 7.4 would be in the minimum of 10,000-20,000 dollars.
They start to ask why were upgrading with those numbers.
What did you do to cause these costs?????
We have several huge and critical customers as well but none of them would cause costs like that.
If everything works nicely: Why would you change the release anyway? Why would you back-port new features if you don't accept downtimes?
If something has been working for months there are not that many bugs you can expect. In case of disaster there are still options to fix bugs. That's what commercial guys are here for.
Fortunately we haven't ever seen a situation in which something really severe has been broken.
Buffer overflows: Usually this kind of bugs can be fixed within just a few lines.
I have been working with PostgreSQL for 4 years now. All together I have encountered 3-4 bugs which caused me some headache and which I haven't known. I guess 1 per year is more than acceptable.
Regards,
Hans
-- Cybertec Geschwinde u Schoenig Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria Tel: +43/2952/30706 or +43/660/816 40 77 www.cybertec.at, www.postgresql.at, kernel.cybertec.at
---------------------------(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
