Forum OpenACS Q&A: Re: PG 7.2->7.3 upgrade gotcha?

Collapse
Posted by Michael Steigman on
What I have now: a huge file containing definitions for functions with names > 31 from 4.6.1 along with drop command for the truncated functions of the same name. If anyone would like a copy of it, let me know.

I'm willing to work with someone to mold this into a general solution. What else would be needed? How should non-core packages be handled (the only non-core stuff I have installed is photo album and lars-blogger)? Also, if this were to become a general solution, it would probably make more sense to redefine the functions using definitions from a PG 7.3 compatible release, i.e., 4.6.3 (or maybe 4.6.4), and then note that the upgrage path from 7.2 to 7.3 must go through that particular release (I don't think we want to maintain this monstrosity for each release, do we?).

Having a naming convention for breaking out non-DML stuff would be great. Almost every new module I've seen does this for its package code but each seems to use its own naming convention.

Collapse
Posted by Andrew Piskorski on
Michael, your one big huge file duplicating all the plpgsql functions with long names is a good solution for people faced with this problem right now with the same version of OpenACS (4.6.1) you're using.

But no, it wouldn't make sense at all to maintain that indefinitely as part of the regular OpenACS release. (Having the same function defined redundantly in two different places is almost always a bad idea.)

The correct general solution is to establish an OpenACS wide convention like I was talking about above. Then there will be no need for duplicate copies of function definitions, you'd simply write a little script to find and source all the "sql/postgresql/*-pb.sql" files or whatever.

Converting all the packages to a particular naming convention should be pretty straightforwad, but there's definitely a fair amount of drudgery involved, and it does require touching all those source files and being careful about it. So in the interim, Michael, for OpenACS 4.6.2 or 4.6.3 users, if you have either some script to automatically generate the "one big file" solution you came up with for 4.6.1, or a similar file for those newer versions of OpenACS, that would probably be quite useful to anyone using those versions of OpenACS who needs to upgrade from PostgreSQL 7.2 to 7.3.

In fact, the changing of packages to match a new naming convention would probably need to be done on the Head (currently what will become OpenACS 5.0), and likely anyone upgrading to 5.0 will have already upgraded from PostgreSQL 7.2 to 7.3?

There is no reason for this naming convention to be any difference for core and non-core packages. If we establish an organizing and naming convention, then we can and should change all packages to use it, core or not. Naturally, the core packages would probably get done first.