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.
