Forum OpenACS Q&A: Compatibility matrix and OpenACS 5.7

Looking at the Compatibility Matrix (, I can't see which versions of Tcl, PostgreSQL or Oracle are compatible with OpenACS 5.7?

There are no versions of Tcl, PostgreSQL and Oracle stated as being compatible. It seems to suggest that OpenACS 5.7 might with PostgreSQL 8.1 (or even 8.0) and Tcl 8.4. Is this something I should chance (before updating PostgreSQL to a later version)?

Posted by Michael Bluett on
Some essential background: I'm trying to upgrade an older version of OpenACS (5.2.3), which can run on PostgreSQL 8.1 to the latest version of OpenACS.
Posted by Dave Bauer on

OpenACS 5.7 Requires Postgresql 8.3 or higher.

I am upgraded two 5.2 sites recently to 5.7 with no problems.

Basically dump the database. Then import into Postgresql 8.3 database and then update your code to OpenACS 5.7 and start it up.

You should visit /acs-admin/apm/ and click "Install Packages".

I recommend a a three step upgrade.

1) upgrade acs-kernel, acs-authentication, restart
2) upgrade remaining core packages, restart
3) upgrade remaining optional packages, restart.

Posted by Jim Lynch on

Heya Dave and the group,

I have copied the content of the compatibility matrix so I can play with it, and here's the copy. I put a green spot for openacs-5.7 and postgres-8.3 onward, with a link to this thread; I'm asking for success reports related to 5.6 and 5.7 on all relevent components. If you've tested with tcl-8.5.x, please say so.

What are the compatibilities with the other components?

  • Anyone paying attention to oracle anymore?

  • I understand aolserver is now at 4.5.2; what's the minimum aolserver version compatible with 5.7? Maybe 4.0.10?

  • I also assume tcl-8.4 is the minimum usable; has anyone tested with tcl-8.5?

Posted by Jim Lynch on
In addition to any "works great!" comments being very welcome, I'd also like to entertain replies with automated test runs. Thanks!
Posted by Torben Brosten on
pg 8.3, oacs 5.7, tcl8.5.11 works well.

I think the emphasis continues to be on keeping openacs releases compatible with the current OS releases for each of platforms.

FreeBSD is a main, stable release platform, because of ongoing, proactive work provided by the group and others.

I've been unsuccessful at installing openacs on ubuntu under limited time constraints; Apparently, ubuntu is using the releases from Debian, which are stable on Debian, but don't necessarily work well on ubuntu, due to release timing, changing dependencies etc.

The main OpenACS issue seems to be upgrading between pg8.3 and pg8.4, namely dealing with changes in tsearch and perhaps ltree. At least tsearch has been incorporated into the main distribution, changing references and requiring some openacs code changes. I believe there's a thread or two about that. I haven't made the jump to pg8.4 locally, so haven't collected the references for that yet.



Posted by Gustaf Neumann on
AOLserver: The latest release of aolserver is 4.5.1. The compatibility matrix should depend on releases, not on head versions. So far, we did not distinguish the releases on the third level, unless we have to. i would place into OpenACS-5.7/aolserver-4.0 a "maybe".

Tcl: TIP #143 approved to make Tcl 8.5 a platform requirement for OpenACS 5.6+. Tcl 8.4.* is not maintained anymore (see the tip for a more detailed rationale). Therefore would should put a "no" into OpenACS-5.7/tcl-8.4, although it might probably continue to work for a while.

Concerning versions of PostgreSQL: OpenACS 5.8 (currently, the head version) works with pg 9.1 as it is shipped (with the postgres configuration out of the box). I implemented the related changes in July last year. The summary of changes below is from my mailing to oct from this time (just updated version numbers and dropped unnecessary stuff), but might help maintaining the compatibility matrix...

best regards
-gustaf neumann

PostgresSQL 9.1 was released in Sept 2011 and has - among a long list of other changes - one noticeable change for OpenACS: the default handling of standard conforming strings has changed [1] (instead of the non.standard backslash escaping). This change effects nspostgres as well as many of the .sql files in oacs-core, which are written in the hard-to-read single-quote style with backslash escapes, and not in the recommended $$-quoting style of PL/pgSQL (see e.g. [2]). I think, we should take the opportunity, update the quoting style and bring the sql files closer to the current state of the art in pg. Sooner or later pg 9.1 will be standard in the Linux distros.

Some deficits of the current .sql-files are:

  • single quotes around the functions (quoting hell1)
  • using backslash escapes (quoting hell2)
  • using function arg aliases instead of writing the argument names in the function definition line
  • using the home-made define_function_args instead of function argument defaults (many definitions for function_args are missing, many defined ones are incomplete - therefore the xo::db-procs relied on the comments in the function argument's alias definitions).
  • with the defaults for function arguments in use, one could query defaults/names/types directly from the pg catalog tables.
One consequence of not using the argument defaults of PL/pgSQL (for obvious reasons, they were not available when these functions were implemented) is that some sql-files have many definitions of the same function with different long argument lists, which are not needed anymore, when defaults are used.

Since i did not want to express just wishes, I invested some more time on the feasibility of such changes, and i think, performing all these changes in one swap is too ambitious for various reasons (more details below), so i would suggest the following two steps:

Step 1:

  • upgrade to the $$ notation (recommended since pg8.0, jan 2005).
  • get rid of backslash usages in function definitions
  • drop aliases in favor of named function arguments (recommended since pg8.0)
  • fix wrong function_args, add missing function_args, align default semantics with the defaults in pg (providing "null" as default means the argument is optional).
Note, that the oldest community supported version of pg is 8.2 [3]. Current versions of OpenACS (since 5.2) need at least 8.0 anyhow [4].

The second step is more ambitious, since it requires sites to use at least pg8.4 and requires argument renaming (or keeping function-args or similar for name mapping, which is as well a hack).

Step 2:

  • use function argument defaults of PL/pgSQL (supported since pg 8.4, feb 2008).
  • the function_args hack would not be needed anymore,
  • but:
    • redundant definitions must be removed (if there is a function with all defaults specified, functions with the same types but less arguments are not allowed)
    • names of the function arguments have to be updated to match the ones provided currently via function_args(). The names in the function argument aliases are named like e.g. "v_item_id", while the names in the function_args are like "item_id". Without renaming, db_exec and maybe other functions would require different variable names. Changing this does not appear feasible.
Requiring pg8.4 is in my opinion still too early. In order to perform upgrades under 9.1, just the first step is needed. For step 2, it might be as well necessary to upgrade the upgrade scripts (newer than oacs 5.2), but i have not looked into this detail yet.

All the changes of Step 1 for OpenACS core are committed to CVS since July 2011. Fresh installations run the regression test (aa-test) under pg 9.1. I have tested the same version as well successfully with pg 8.4.

The change is huge.

-gustaf neumann


Posted by Jeff Rogers on
Is there a reason why postgresql schemas (available since 7.3, although it's possible they were not fully functional until later) are not used? It seems like they would be a little nicer to work with than the '__' namespacing convention currently used, although such a change would be mostly cosmetic. Such a change would be huge, but maybe individual packages could adopt it.

Another mostly cosmetic change that would be nice to adopt is the availability of anonymous code blocks, (i.e., 'DO ...' rather than creating a function and calling it immediately), but that's only since pg9.0 which is at least for now too much dropping backward compatibility.

Posted by Jim Lynch on
they are used... you can't not use them. there is a schema named public that's created by default, and everything is created inside that schema.
Posted by Jeff Rogers on
This isn't using schemas, any more than tablespaces or toasted attributes are being used. Yes, they are being used but only because you can't not use them; but the additional functionality they provide isn't used.

They could be used as a namespacing mechanism; for example the calendar package might use a 'calendar' schema with a 'new' function within that schema (similar to oracle packages), and the function would be '' rather than 'calendar__new'.

Would there be any tangible benefit from doing so? Hard to say, it's mostly just a naming convention. But there also seems to be no downside, which is why wondering why they aren't used. (changing everything to using '.' instead of '__' is obviously a pretty big disruption of course)

Posted by Gustaf Neumann on
yes, using SQL schemas would certainly make the system prettier.

The reason, why SQL schemas are not used in OpenACS is for historical reasons: when the postgres port was done, schemas were not supported by postgres. When using schemata, it would certainly make sense to move not only stored procedures into the schema space, but as well the tables defined by the packages, every package could be contained in a tcl namespace and sql schema ... and then, one should do the same for oracle as well. As you mentioned the benefit is not huge; from my experience is more likely that you get hate-mails, when you break something, than love-mails, when the components work as before.

I see a move to SQL schemas of less priority than Step-2 above (currently, debugging the function with the varying argument lists is painful, querying the default values from the postgres meta data does not work, we have hacks in OpenACS to work around this).