hi jim,
concerning backslash escapes: read section E.9.2.1 in reference [1] above. The backslash (as in e.g. "...\n...") is in the SQL standard an ordinary character, postgres moves this way. The backslashes in SQL strings are introduced in part in the OpenACS source code, and in part from the postgres drivers (which i have updated for aolserver and naviserver as well one or two years ago). One can get the old escape behavior also in new postgres versions via turning standard conforming strings off, but this is not recommended (and might be a problem, when the same database is used for multiple applications, ... or when using packaged database installations, etc).
Concerning defaults: the PL/pgSQL functions of OpenACS did not and still do not use default values, but there are many documentational defaults (saying in a comment that the value defaults to whatever) in the code. Since the the postgres functions were implemented before real defaults were available, the code uses many function with different signatures handling the "defaults" for the missing arguments programmatically. See e.g. the various definitions of content_item__new:
-- procedure content_item__new/20
-- procedure content_item__new/19
-- procedure content_item__new/17
-- procedure content_item__new/17
-- procedure content_item__new/16
-- procedure content_item__new/16
-- procedure content_item__new/16
-- procedure content_item__new/15
-- procedure content_item__new/6
-- procedure content_item__new/5
-- procedure content_item__new/3
-- procedure content_item__new/2
The new function definitions with the named function arguments are nothing more but a requisite to handle this case easier in the future with PL/pgSQL defaults. Using the function argument defaults of PL/pgSQL are supported since pg 8.4, feb 2008. Requiring functions argument defaults now is probably still to early, since once these are used, people are forced to new versions. For several large installations, moving from postgres 8.3 to 8.4 was no good option (see [a]). Since yesterday, we have the victors changes for using recursive queries for permissions in openacs head, so also performance-wise we can now recommend to upgrade to recent PostgreSQL versions.
The comment about "null" was for OpenACS's own way of providing default values via define_function_args
.
The rework of the SQL files of OpenACS do not provide any functional changes are they are pure boring maintenance work. But these changes are actually essential for OpenACS. While one can dump/restore old OpenACS databases from earlier versions to e.g. 9.2, one cannot source upgrade scripts or load packages without these modifications.
Hope, this makes the picture clearer.
-gustaf neumann
PS: Btw, i have not touched the upgrade scripts of acs-kernel and acs-content-repository. So it is recommended to run the upgrade scripts in an old postgres installation before switching to 9.*
[a] https://openacs.org/forums/message-view?message_id=3814195