Forum OpenACS Q&A: Re: Compatibility matrix and OpenACS 5.7

Collapse
7: Re: Compatibility matrix and OpenACS 5.7 (response to 4)
Posted by Gustaf Neumann on 06/04/12 09:35 AM
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

[1] http://www.postgresql.org/docs/9.1/static/release-9-1.html
[2] http://www.postgresql.org/docs/9.0/interactive/plpgsql-declarations.html
[3] http://en.wikipedia.org/wiki/PostgreSQL
[4] https://openacs.org/xowiki/openacs-compatibility-matrix

Collapse
8: Re: Compatibility matrix and OpenACS 5.7 (response to 7)
Posted by Jeff Rogers on 06/04/12 06:59 PM
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.