Forum OpenACS Q&A: Should we drop support of Postgres 7.2 in OpenACS 5.0/.LRN 2.0?
There are issues like timestamp, function names and view names. So that we can upgrade our custom packages as well.
7.3.x is well field tested now, it means you can re-write procedures without the annoying 16 param limit in mind, and for a non point number release there is nothing wrong with the removal of previous database version compatability.
If people (like me) have custom packages, they can run production sites on 4.6.3 and migrate to a development system running 5.0/7.3.x
I think prodding people forward like this is good for everyone, its not like commerical software with a 'we will no longer support you if you do not upgrade' clause, so there is no gun to anyones head.
A necessity would then be to include Yun's excellent perl script that restores truncated identifiers to their original length, dump_parser.pl (maybe with a more informative name, e.g. pg_upgrade_helper.pl?). Yun, do you want to commit it to the the bin/ directory in CVS?
I don't think it should be committed to CVS. Since the script is one off. And its also not 100%. It is indicated on the script that is not 100%, although it did help some including openacs.org.
But I hope someone can make a short doc what are the issues moving from 7.2. to 7.3.
Take me as a prime example.
During the time the migration issues was being discussed, I was not paying too much attention to oacs. When I finally needed to upgrade. I have an idea what where the issues. But it took Jade in IRC to somehow explain to me about the function name problem.
I can volunteer to do the write up about the name functions 32 char length. Which also affects views, etc. But someone else would need to step up and explain the other issues (which I still need to fully understand). Then we come up with a 1 pager simple readme. Put it into the docs, so it will help others migrate.
I was hoping that committing the file to CVS would be a step towards making it work for others, and we definitely need something like that anyway if we want to allow to upgrade openacs installations from pg 7.2 to 7.3. For example if it was in CVS it would be easier for me to re-run it and try to reproduce and fix the one bug I experienced.
Could you please reconsider this or better just commit it? ;)
And for future versions of OpenACS that don't need it anymore, there's 'cvs remove'.